Повысьте производительность своего веб-сайта, изучив политики кэширования
Современные фреймворки javascript, такие как React.js, Next.js и т. д., повысили удобство работы конечных пользователей и разработчиков благодаря более модульному декларативному стилю разработки. Виртуальные DOMS и сравнение помогли оптимизировать манипуляции с DOM.
Но для браузера рисование DOM — не единственное, о чем нужно беспокоиться. Он также имеет дело с файлами и сетевыми вызовами; для создания страницы используется куча HTML, CSS, JS, шрифтов, изображений и т. д.
Как говорит Сэм Торогуд в этом видео, фронтенд-инженеры чаще сосредотачиваются на улучшении оценки Lighthouse, которая в основном фокусируется на опыте первой загрузки веб-сайта. Мы также должны отдавать приоритет второй (или последующей) скорости загрузки, когда пользователи повторно посещают веб-сайт. Здесь на помощь приходят кэширование и эффективные политики кэширования.
Кэширование — это идея хранения повторно используемых данных на уровне высокоскоростного хранилища данных, чтобы их можно было быстрее извлекать для обслуживания будущих запросов.
Если некоторые файлы на веб-сайте изменяются нечасто, браузеры могут кэшировать их, чтобы они быстрее обслуживались для будущих запросов и сохраняли множество сетевых вызовов. (и счета за интернет!)
«В компьютерных науках есть только две сложные вещи: аннулирование кеша и присвоение имен вещам». — Фил Карлтон
В этой статье я хочу поделиться тем, что я узнал о кэшировании в Интернете.
Обзор
Вот упрощенный вид, чтобы лучше понять основных вовлеченных игроков. Наряду с кешем на стороне клиента у нас также есть общие кеши, реализованные на прокси-серверах или CDN, которые могут использовать несколько клиентов.
Кэширование ресурса осуществляется с помощью HTTP-заголовка Cache-Control
. Он имеет как директивы запроса, так и директивы ответа, которые сообщают браузерам и общим кешам, как обращаться к ресурсу (подробнее об этом позже).
Краткий обзор кэширования на стороне браузера
Вот моя страница профиля в Твиттере, загружаемая впервые (или после очистки кеша и жесткой перезагрузки). Обратите внимание на вкладку «Размер и время».
Вот второй раз открываю. Обратите внимание, что время резко сократилось.
И вот он каждый раз, когда я его открываю. Загружается за 0 мс.
Такие элементы, как логотип Twitter, значки, баннер моего профиля, изображения профиля и т. д., меняются не так часто и поэтому кэшируются.
Но зачем там дисковый кеш и кеш памяти?
Типы кешей в браузере (Chrome)
В Google Chrome есть четыре типа кэшей:
- Кэш памяти: Кэш памяти — это кратковременный кеш, в котором хранятся все ресурсы, кэшированные в течение времени жизни текущего документа (непостоянный). Ресурсы, кэшированные здесь, остаются до закрытия вкладки/сеанса. Он хранится в памяти.
- Кэш диска. Кэш диска (HTTP-кэш) — это постоянный кеш, который позволяет повторно использовать ресурсы между сеансами и между сайтами. Это дисковый кеш.
- Кэш сервис-воркера: у сервис-воркера есть API кеша, который мы можем использовать для управления кешем, и он является постоянным. Сервисные работники — это файл JS, фундаментальный компонент создания PWA (Progressive Web Apps).
- Push-кеш: Push-кеш — это место, где хранятся push-ресурсы HTTP/2. Отправка — это метод оптимизации производительности, при котором сервер отправляет браузеру некоторые ресурсы, прежде чем он их запрашивает. Мы не будем вдаваться в подробности здесь, так как даже я выясняю, как именно это используется (дайте мне знать, если вы знаете больше о push-кэшировании).
Об этом подробнее здесь".
Примечание.Кэш сервис-воркера будет существовать только в том случае, если на странице зарегистрирован сервис-воркер.
JS-файлы Twitter загружаются из Service
worker Cache. Это связано с тем, что веб-приложение Twitter является PWA, поэтому в нем зарегистрирован сервисный работник.
Поток кэширования браузера
Согласно web.dev, браузер следует порядку кэширования при проверке ресурса. Кэш памяти существует над кешем Service worker (отсутствует на рисунке ниже).
Инструменты объединения и очистка кеша
Допустим, на вашем сайте есть index.html
, script.js
и style.css
. Вы хотите, чтобы элементы кэшировались в течение длительного времени (например, год или около того), но вы также регулярно вносите изменения в script.js
и style.css
и развертываете их. Поскольку имя не меняется, пользователям будут предоставляться файлы из кеша.
Очистка кеша — это способ решить эту проблему, когда мы используем версии или хэши в именах файлов, чтобы браузер мог их загрузить и обновить кеш.
Мы бы запретили браузеру кэшировать файл HTML, а файлы, загруженные в теги <link>
или <script>
, также будут иметь версию в своих именах (в основном это содержимое), чтобы браузер мог загрузить их и обновить кеш.
Если вы использовали webpack или аналогичные инструменты для создания своего приложения (или использовали что-то вроде CRA), вы, должно быть, видели связанные файлы CSS и JS со странными именами в формате main.[content-hash].js
. Всякий раз, когда содержимое файла изменяется, хэш содержимого также изменяется.
Заголовок Cache-Control
Это святой Грааль кэширования в сети. Заголовок управления кешем, который является частью ответа сервера, может сообщить браузерам или прокси-серверам, следует ли кэшировать ресурс, как долго он должен кэшироваться, следует ли повторно проверять его и т. д.
Например, приведенная выше конфигурация говорит, что ответ может храниться в кеше в течение недели и повторно использоваться, пока он свежий. Если ответ становится устаревшим, его необходимо проверить на исходном сервере перед повторным использованием (из-за директивы ответа must-revalidate
).
Это может быть настроено в соответствии с нашими потребностями и довольно обширно. Я нашел MDN docs лучшим местом, чтобы узнать об этом. Вот отличная статья Джейка Арчибальда о лучших методах кэширования.
Проверка, ETags и код состояния HTTP 304
Предположим, что файл находится в кеше, и браузер должен перепроверить его перед использованием. Это можно сделать с помощью entity tag (ETag), а именно. HTTP-заголовок. Значение ETag — это идентификатор, представляющий конкретную версию файла. Они также помогают предотвратить перезапись одновременных обновлений файла друг другом. Например:
ETag: "<etag_value>"
Вот простой обзор того, как это работает. Предположим, браузер запрашивает у сервера файл ABC.svg
.
- Сервер отправляет обратно файл, генерирует ETag и прикрепляет его к заголовку ответа вместе с кодом состояния HTTP 200. Затем браузер продолжает кэшировать это.
- Теперь, если браузеру необходимо перепроверить файл в кеше, он отправляет запрос вместе с ранее полученным ETag.
- Затем сервер проверяет ETag файла и, если версия не изменилась, отправляет ответ с кодом состояния HTTP 304, который сообщает браузеру, что файл не был изменен и может повторно использовать старый.< br /> В противном случае сервер отправляет новую версию файла вместе с новым ETag и кодом состояния HTTP 200.
Заключение
Кэширование является жизненно важным компонентом повышения производительности сети. Поэтому важно понимать, как это работает. Этот пост представляет собой простое введение в кэширование, а не подробное руководство.
Спасибо за прочтение!