Применение мгновенной загрузки с помощью шаблона PRPL
PRPL — это аббревиатура, описывающая шаблон, который используется для ускорения загрузки и перехода к интерактивности веб-страниц:
- Push — отправка, или preload — предварительная загрузка, наиболее важных ресурсов.
- Render — обработка начального маршрута в кратчайшие сроки.
- Pre-cache — предварительное кеширование оставшихся ресурсов.
- Lazy load — отложенная загрузка других маршрутов и некритических ресурсов.
Из этого руководства вы узнаете, как использовать каждый из этих методов по отдельности и сочетать их друг с другом для улучшения производительности.
Аудит вашей страницы в Lighthouse #
Запустите Lighthouse, чтобы определить возможности для улучшения в соответствии с методами PRPL:
Откройте DevTools, нажав
Control+Shift+J(илиCommand+Option+J, если у вас Mac).Перейдите на вкладку Lighthouse.
Установите метки «Производительность» и «Прогрессивное веб-приложение».
Щелкните «Выполнить аудит», чтобы создать отчет.
Дополнительные сведения см. в разделе «Откройте для себя возможности повышения производительности с помощью Lighthouse».
Предварительная загрузка критических ресурсов #
Следующий аудит Lighthouse завершается неудачей, если определенный ресурс анализируется и загружается слишком поздно:
Предварительная загрузка — это декларативный запрос на выборку, который сообщает браузеру как можно скорее запросить ресурс. Предварительно загрузите критически важные ресурсы, добавив тег <link> с атрибутом rel="preload" в заголовок своего HTML-документа:
<link rel="preload" as="style" href="css/style.css">Браузер устанавливает подходящий уровень приоритета для ресурса, чтобы попытаться загрузить его раньше, не задерживая событие window.onload.
Дополнительные сведения о предварительной загрузке критических ресурсов см. в руководстве «Предварительная загрузка критических ресурсов».
Обработка начального маршрута в кратчайшие сроки #
Lighthouse выдает предупреждение, если есть ресурсы, которые задерживают First Paint, момент, когда ваш сайт отображает пиксели на экране:
Чтобы улучшить показатель First Paint, Lighthouse рекомендует встраивать критический JavaScript и откладывать остальное с помощью async, а также встраивать критический CSS, используемый в верхней части страницы. Это повышает производительность за счет исключения циклических обращений к серверу для получения ресурсов, блокирующих рендеринг. Однако встроенный код сложнее поддерживать с точки зрения разработки, и браузер не может кешировать его отдельно.
Другой подход к улучшению показателя First Paint — это рендеринг на стороне сервера исходного HTML-кода вашей страницы. С этим подходом контент будет отображен для пользователя немедленно, пока скрипты все еще выбираются, анализируются и выполняются. Однако это может значительно увеличить полезную нагрузку HTML-файла, что может увеличить Time to Interactive, т.е. время, необходимое для того, чтобы ваше приложение стало интерактивным и могло реагировать на ввод пользователя.
Не существует единого правильного решения для уменьшения First Paint в вашем приложении, и следует рассматривать встраивание стилей и рендеринг на стороне сервера только в том случае, если польза перевешивает потенциальный риск для вашего приложения. Вы можете узнать больше об обеих концепциях в следующих ресурсах.
Предварительное кеширование ресурсов #
Действуя как прокси, сервис-воркеры могут при повторных посещениях извлекать ресурсы непосредственно из кеша, а не с сервера. Это не только позволяет пользователям работать с вашим приложением вне сети, но и сокращает время загрузки страницы при повторных посещениях.
Используйте стороннюю библиотеку, чтобы упростить процесс создания сервис-воркера, если ваши требования к кешированию не выходят за рамки возможностей библиотеки. Например, Workbox предоставляет набор инструментов, которые позволяют создавать и поддерживать сервис-воркер для кеширования ресурсов. Для получения дополнительной информации о сервис-воркерах и бесперебойной работе вне сети обратитесь к руководству по сервис-воркерам в рамках программы обучения надежности.
Отложенная загрузка #
Аудит Lighthouse завершается неудачей, если вы отправляете слишком много данных по сети.
Сюда входят все типы ресурсов, но большие полезные данные JavaScript особенно дороги из-за того, что браузеру требуется время, чтобы проанализировать и скомпилировать их. В соответствующих случаях Lighthouse также предупреждает об этом.
Чтобы отправить меньший пакет JavaScript, который содержит только код, необходимый при первоначальной загрузке вашего приложения пользователем, разделите весь пакет и загрузите фрагменты по запросу.
После того, как вам удалось разделить пакет, предварительно загрузите более важные фрагменты (см. руководство по предварительной загрузке критических ресурсов). Предварительная загрузка гарантирует, что более важные ресурсы будут извлечены и загружены браузером раньше.
Помимо разделения и загрузки различных фрагментов JavaScript по запросу, Lighthouse также предоставляет аудит отложенной загрузки некритических изображений.
Если вы загружаете много изображений на свою веб-страницу, отложите все, что находится ниже первого экрана или вне области просмотра устройства, когда страница загружается (см. «Использование lazysizes для отложенной загрузки изображений»).
Следующие шаги #
Теперь, когда вы понимаете некоторые из основных концепций, лежащих в основе шаблона PRPL, перейдите к следующему руководству в этом разделе, чтобы узнать больше. Важно помнить, что не все техники нужно применять вместе. Использование любой из следующих методик обеспечит заметное улучшение производительности.
- Push — отправка, или preload — предварительная загрузка, критических ресурсов.
- Render — обработка начального маршрута в кратчайшие сроки.
- Pre-cache — предварительное кеширование оставшихся ресурсов.
- Lazy load — отложенная загрузка других маршрутов и некритических ресурсов.