Повысьте производительность своего веб-сайта, изучив политики кэширования

Современные фреймворки javascript, такие как React.js, Next.js и т. д., повысили удобство работы конечных пользователей и разработчиков благодаря более модульному декларативному стилю разработки. Виртуальные DOMS и сравнение помогли оптимизировать манипуляции с DOM.

Но для браузера рисование DOM — не единственное, о чем нужно беспокоиться. Он также имеет дело с файлами и сетевыми вызовами; для создания страницы используется куча HTML, CSS, JS, шрифтов, изображений и т. д.

Как говорит Сэм Торогуд в этом видео, фронтенд-инженеры чаще сосредотачиваются на улучшении оценки Lighthouse, которая в основном фокусируется на опыте первой загрузки веб-сайта. Мы также должны отдавать приоритет второй (или последующей) скорости загрузки, когда пользователи повторно посещают веб-сайт. Здесь на помощь приходят кэширование и эффективные политики кэширования.

Кэширование — это идея хранения повторно используемых данных на уровне высокоскоростного хранилища данных, чтобы их можно было быстрее извлекать для обслуживания будущих запросов.

Если некоторые файлы на веб-сайте изменяются нечасто, браузеры могут кэшировать их, чтобы они быстрее обслуживались для будущих запросов и сохраняли множество сетевых вызовов. (и счета за интернет!)

«В компьютерных науках есть только две сложные вещи: аннулирование кеша и присвоение имен вещам». — Фил Карлтон

В этой статье я хочу поделиться тем, что я узнал о кэшировании в Интернете.

Обзор

Вот упрощенный вид, чтобы лучше понять основных вовлеченных игроков. Наряду с кешем на стороне клиента у нас также есть общие кеши, реализованные на прокси-серверах или CDN, которые могут использовать несколько клиентов.

Кэширование ресурса осуществляется с помощью HTTP-заголовка Cache-Control. Он имеет как директивы запроса, так и директивы ответа, которые сообщают браузерам и общим кешам, как обращаться к ресурсу (подробнее об этом позже).

Краткий обзор кэширования на стороне браузера

Вот моя страница профиля в Твиттере, загружаемая впервые (или после очистки кеша и жесткой перезагрузки). Обратите внимание на вкладку «Размер и время».

Вот второй раз открываю. Обратите внимание, что время резко сократилось.

И вот он каждый раз, когда я его открываю. Загружается за 0 мс.

Такие элементы, как логотип Twitter, значки, баннер моего профиля, изображения профиля и т. д., меняются не так часто и поэтому кэшируются.

Но зачем там дисковый кеш и кеш памяти?

Типы кешей в браузере (Chrome)

В Google Chrome есть четыре типа кэшей:

  1. Кэш памяти: Кэш памяти — это кратковременный кеш, в котором хранятся все ресурсы, кэшированные в течение времени жизни текущего документа (непостоянный). Ресурсы, кэшированные здесь, остаются до закрытия вкладки/сеанса. Он хранится в памяти.
  2. Кэш диска. Кэш диска (HTTP-кэш) — это постоянный кеш, который позволяет повторно использовать ресурсы между сеансами и между сайтами. Это дисковый кеш.
  3. Кэш сервис-воркера: у сервис-воркера есть API кеша, который мы можем использовать для управления кешем, и он является постоянным. Сервисные работники — это файл JS, фундаментальный компонент создания PWA (Progressive Web Apps).
  4. 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.

  1. Сервер отправляет обратно файл, генерирует ETag и прикрепляет его к заголовку ответа вместе с кодом состояния HTTP 200. Затем браузер продолжает кэшировать это.
  2. Теперь, если браузеру необходимо перепроверить файл в кеше, он отправляет запрос вместе с ранее полученным ETag.
  3. Затем сервер проверяет ETag файла и, если версия не изменилась, отправляет ответ с кодом состояния HTTP 304, который сообщает браузеру, что файл не был изменен и может повторно использовать старый.< br /> В противном случае сервер отправляет новую версию файла вместе с новым ETag и кодом состояния HTTP 200.

Заключение

Кэширование является жизненно важным компонентом повышения производительности сети. Поэтому важно понимать, как это работает. Этот пост представляет собой простое введение в кэширование, а не подробное руководство.

Спасибо за прочтение!

Дополнительная литература и ссылки