От автора: PRPL — это шаблон, используемый для создания масштабируемых, быстрых современных веб-приложений с отличным пользовательским интерфейсом.
PRPL — это аббревиатура от:
Push (или предварительно загрузите) самые важные ресурсы
Сделайте начальный маршрут как можно быстрее
Предварительно кешируйте оставшиеся активы
Отложено загрузите другие маршруты и некритические ресурсы
Архитектура PRPL была задумана командой Google Chrome, стремящейся сделать Интернет быстрее.
PRPL — это индивидуальный прием оптимизации, разрабатывавшийся на протяжении многих лет, который призван облегчить работу в Интернете. Он включается в себя Service Workers, фоновую синхронизацию, Cache API, подсказки приоритета и предварительное извлечение.
В частности, PRPL подходит для телефонов в плохой сети, когда телефон находится в автономном режиме или в режиме экономии данных. В этом посте мы рассмотрим каждый аспект PRPL.
P — Push (или предварительная нагрузка)
Это указывает браузеру заранее получить ресурс и сохранить его в браузере. Поэтому, когда нам нужен ресурс, он быстро извлекается из браузера без извлечения ресурса по сети. Это делается с помощью rel=»preload».
Предварительная загрузка — это декларативный запрос на выборку, который сообщает браузеру как можно скорее запросить ресурс. Предварительно загрузите важные ресурсы, добавив тег link с rel=»preload» в заголовок HTML-документа – Хуссейн Джирдех web.dev.
Для предварительной загрузки ресурса мы используем тег ссылки и добавляем к нему атрибут rel=’preload’.
<link rel="preload" as="style" href="style.css">
Это указывает предварительно загрузить ресурс style.css как таблицу стилей. Атрибут as=’style’ сообщает браузеру, что предварительно загружаемый ресурс представляет собой таблицу стилей и должен быть загружен соответственно. Ресурсы, которые можно предварительно загрузить:
Веб-страница
Файлы JS
Файлы CSS
Медиа-файлы (аудио, изображения, видео, документы и веб-шрифты)
Поиск DNS
<link rel="preload" href="/your/webpage/link"> <link rel="preload" href="/your/js/file/link"> <link rel="preload" href="/your/css/file/link"> <link rel="preload" href="/your/audio/file/link"> <link rel="preload" href="/your/audio/file/link"> <link rel="preload" href="/your/video/file/link"> <link rel="preload" href="/your/image/file/link"> <link rel="preload" href="/your/document/file/link"> <link rel="preload" href="/your/webfont/file/link">
Предварительная загрузка и предварительное извлечение в основном одинаковы.
Предварительное извлечение включает в себя процесс, при котором браузер извлекает ресурсы тега link и сохраняет их в локальном кеше. Когда пользователь в конечном итоге запрашивает страницу через тег link, браузер обслуживает пользователя кэшированной страницей. Это ускоряет загрузку и отображение веб-страницы.
Для предварительного извлечения ресурса мы используем атрибут rel=»prefetch».
<link rel="prefetch">
Это выполнит предварительную загрузку всех имеющихся ресурсов, как и предварительная загрузка.
R — исходный рендеринг
Это правило гласит, что начальный маршрут веб-приложения должен отображаться как можно быстрее и что начальный маршрут не должен загружаться отложено.
Мы называем это Initial Contentful Paint. Независимо от того, что делает приложение, оно должно быстро произвести первую отрисовку в браузере. Чтобы оптимизировать первую отрисовку содержимого, мы должны устранить ресурсы, блокирующие рендеринг, оптимизировать доставку CSS и использовать SSR.
Это в основном применимо к фреймворкам JS, потому что они отображают полезную нагрузку в браузере / на стороне клиента, поэтому, если приложение имеет большую полезную нагрузку, вы увидите, что ему придется загрузить активы JS / CSS перед рендерингом содержимого.
Таким образом, SSR в вашем веб-приложении поможет отобразить веб-приложение на сервере и произвести первую отрисовку до того, как прибудет остальная часть JS / CSS.
Например, в React мы можем создать приложение с рендерингом на стороне сервера, используя ReactDOMServer. Рассмотрим пример:
import React from "react" import ReactDOM from "react-dom" import App from "App" ReactDOM.hydrate(<App />, window.root)
Мы используем вместо рендеринга ReactDOM.hydrate, потому что хотим, чтобы рендерер React DOM знал, что мы повторно гидрируем приложение после рендеринга на стороне сервера. Это означает, что средство визуализации React DOM будет ожидать рендеринга с сервера. Оно будет отображать его первым. Затем компонент приложения React поступает из браузера.
Далее сервер Express будет таким:
import fs from "fs" import React from "react" import App from "./App" import ReactDOMServer from "react-dom/server" ... app.get("/", (req, res, next) => { // This would render the <App /> and return it as string. const app = ReactDOMServer.renderToString(<App />) fs.readFile("./build/index.html", (err, data) => { // We read the index.html file, replace the `div#root` with the rendered App component and send it to the browser. return res.send(data.replace("<div id='root'></div>", "<div id='root'>" + app + "</div>")) }) }) ...
С помощью приведенного выше кода приложение React теперь поддерживает SSR. Оно будет отображать первую отрисовку до того, как будет отрисована вся нагрузка. Доставка CSS включает в себя встраивание важного CSS в HTML, поэтому он доставляется быстро.
Все это поможет веб-приложению быстро отобразить первоначальный маршрут и стать интерактивным до того, как прибудет остальная полезная нагрузка. Это улучшает производительность и удобство использования.
P — предварительное кеширование
Это метод, при котором активы кэшируются в браузере, поэтому при выполнении запросов на актив они обслуживаются из кеша, не мешая взаимодействию с пользователем. Это очень полезно, когда телефон отключен.
Таким образом, вместо того, чтобы пользователь видел сбой сети, обслуживаются кэшированные ресурсы. Когда телефон подключается к сети, ресурсы обновляются из сети.
Предварительное кэширование выполняется с помощью service worker и в основном используется в PWA. У service worker есть разные стратегии предварительного кэширования:
Stale-while-revalidate: эта стратегия проверяет ответ в кеше. Если он доступен, то доставляется, и кэш повторно проверяется. Если он недоступен, service worker получает ответ из сети и кэширует его.
Сначала кэш: эта стратегия сначала ищет ответ в кэше. Если какой-либо ответ обнаружен ранее кэшированным, он возвращается из кеш. Если нет, то ответ получается из сети, обслуживается и кэширует для следующего раза.
Сначала сеть: при этой стратегии мы сначала пытается получить ответ из сети. В случае успеха мы кэшируем ответ и возвращает его. Если сеть недоступна, ответ вернется из кэша.
Только кэш: Эта стратегия отвечает только из кэша. Он не возвращается в сеть.
Только сеть: Эта стратегия использует для получения и передачи ответа исключительно сеть. Нет отката к кэшу.
Есть библиотека под названием Workbox от Google. Она предназначена для предоставления инструментов для обслуживания кэша в service worker, а также предоставляет на выбор стратегии кэширования, которые мы только что рассмотрели. Давайте посмотрим, как применять Workbox для предварительного кэширования.
Используя Workbox, мы устанавливаем маршрут и стратегию кэширования, которую хотим использовать. Workbox будет прослушивать запрос маршрута и определять, как запрос будет кэшироваться и отвечать на него.
import { registerRoute } from 'workbox-routing'; import { NetworkFirst } from 'workbox-strategies'; registerRoute( // We are caching the style resources. ({request}) => request.destination === 'style', // We are setting the style cahcing to use the // StaleWhileRevalidate strategy. // Use cache but update in the background. new StaleWhileRevalidate() );
Выше приведен простой пример того, как кэшировать ресурсы стилей в Workbox, чтобы использовать стратегию StaleWhileRevalidate. Это кэширует все наши файлы стилей для более быстрой загрузки при перезагрузке. Они незаметно обновляются в фоновом режиме при наличии сети.
registerRoute( ({request}) => request.destination === 'script', new NetworkFirst() );
Здесь все наши файлы JavaScript кэшируются с использованием стратегии Сначала сеть. Они извлекаются из кеша при сбое загрузки по сети.
L — отложенная загрузка
Она откладывает загрузку маршрутов и ресурсов в веб-приложении на другое время.
Наиболее важными понятиями производительности приложения являются время отклика и потребление ресурсов. Это неизбежно. Проблема может возникнуть откуда угодно, и важно найти и устранить проблемы до того, как они возникнут.
Отложенная загрузка помогает снизить риск многих проблем с производительностью веб-приложений до минимума. Отложенная загрузка оптимизирует перечисленные выше аспекты:
Время отклика: это количество времени, которое требуется веб-приложению для загрузки и пользовательского интерфейса, чтобы реагировать на запросы пользователей. Отложенная загрузка оптимизирует время отклика за счет разделения кода и загрузки нужного пакета.
Потребление ресурсов: Люди — существа нетерпеливые. Нам не нравится, когда сайт загружается более 3 секунд. За это время 70 процентов из нас сдадутся. Веб-приложения не должны загружаться так долго. Таким образом, чтобы уменьшить объем загрузки ресурсов, при отложенной загрузке загружается только пакет кода, необходимый в данный момент.
Отложенная загрузка может быть выполнена в Chrome изначально без помощи внешних библиотек. Другими словами, отложенная загрузка будет нативно поддерживаться браузером.
Это так же просто, как добавить к ресурсам, которые мы хотим загружать отложено, атрибут loading. Например, у нас есть изображение:
<img src="./big-image.jpg" />
Чтобы нативно отложено загрузить это изображение, мы просто добавляем атрибут loading со значением «lazy»:
<img src="./big-image.jpg" loading="lazy" />
Атрибут loading является ключевым. Он сообщает браузеру, что этот ресурс не следует загружать быстро, если не указано иное. Этот атрибут может быть включен в теги image, iframe, video и audio для их отложенной загрузки. Атрибут loading имеет различные значения, мы можем выбирать из:
lazy: это значение заставляет браузер откладывать загрузку ресурса до тех пор, пока он не попадет в область просмотра браузера.
auto: указывает на отсутствие отложенной загрузки ресурса.
eager: это указывает загрузить ресурс немедленно, без отложенной загрузки.
Отложенная загрузка также может выполняться программно с помощью Intersection Observer API. Библиотеки в Angular, React и Vue используют Intersection Observer для отложенной загрузки компонентов и ресурсов.
Заключение
В этом посте мы рассмотрели, что такое PRPL. Это шаблон или набор методов, установленных современными веб-стандартами, которые диктуют, как оптимизировать веб-приложение для повышения эффективности. Мы продолжили изучение различных методов, от предварительной загрузки и предварительного извлечения до отложенной загрузки.
В целом стандарты установлены. Нам просто нужно следовать им, чтобы создавать невероятно быстрые современные веб-приложения. Будущее уже наступило.
Автор: Chidume Nnamdi
Источник: https://blog.logrocket.com
Редакция: Команда webformyself.