Предотвратите ненужные сетевые запросы с помощью HTTP-кеша

Ilya Grigorik

Jeff Posnick

Получение ресурсов по сети является медленным и дорогостоящим процессом:

• Большие ответы требуют большого количества обращений между браузером и сервером.
• Ваша страница не загрузится, пока все важные ресурсы не будут загружены полностью.
• Если у пользователя вашего сайта ограниченный тарифный план на передачу мобильных данных, каждый ненужный сетевой запрос — это пустая трата его денег.

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

В этом руководстве показаны основы эффективной реализации HTTP-кэширования.

Совместимость с браузером

HTTP-кэш — это общее название набора API-интерфейсов веб-платформы, поддерживаемых во всех браузерах:

Cache-Control

Поддержка браузера

• Истинный
• 12
• Истинный
• Истинный

Источник

ETag

Поддержка браузера

• Истинный
• 12
• Истинный
• Истинный

Источник

Last-Modified

Поддержка браузера

• Истинный
• 12
• Истинный
• Истинный

Источник

Как работает HTTP-кэш

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

Поведение HTTP-кэша контролируется комбинацией заголовков запроса и заголовков ответов . В идеальном сценарии вы контролируете как код вашего веб-приложения, который определяет заголовки запросов, так и конфигурацию вашего веб-сервера, которая определяет заголовки ответов.

Более подробный концептуальный обзор можно найти в статье HTTP-кэширования MDN.

Заголовки запросов: придерживайтесь значений по умолчанию (обычно).

Существует ряд важных заголовков, которые следует включать в исходящие запросы вашего веб-приложения, но браузер почти всегда заботится о том, чтобы установить их от вашего имени при отправке запросов. Заголовки запросов, влияющие на проверку актуальности, такие как If-None-Match и If-Modified-Since отображаются на основе понимания браузером текущих значений в HTTP-кеше.

Это хорошая новость: это означает, что вы можете продолжать включать такие теги, как <img src="my-image.png"> в свой HTML, и браузер автоматически позаботится о кэшировании HTTP без дополнительных усилий.

Примечание. У разработчиков, которым требуется больший контроль над HTTP-кешем в их веб-приложении, есть альтернатива: вы можете использовать Fetch API вручную, передавая ему объекты Request с определенными установленными переопределениями cache . Однако это выходит за рамки данного руководства.

Заголовки ответов: настройте свой веб-сервер

Наиболее важная часть настройки HTTP-кэширования — это заголовки, которые ваш веб-сервер добавляет к каждому исходящему ответу. Следующие заголовки влияют на эффективное поведение кэширования:

Cache-Control

Сервер может вернуть директиву Cache-Control чтобы указать, как и как долго браузер и другие промежуточные кэши должны кэшировать отдельный ответ.

ETag .

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

Last-Modified

Этот заголовок служит той же цели, что и ETag , но использует основанную на времени стратегию для определения того, изменился ли ресурс, в отличие от стратегии ETag , основанной на контенте.

Некоторые веб-серверы имеют встроенную поддержку настройки этих заголовков по умолчанию. Другие полностью оставляют заголовки, если вы явно не настроите их. Конкретные детали настройки заголовков сильно различаются в зависимости от того, какой веб-сервер вы используете, и вам следует обратиться к документации вашего сервера, чтобы получить наиболее точную информацию.

Чтобы сэкономить вам время на поиски, вот инструкции по настройке нескольких популярных веб-серверов:

• Выражать
• Апач
• nginx
• Хостинг Firebase
• Нетлифай

Отсутствие заголовка ответа Cache-Control не отключает кэширование HTTP! Вместо этого браузеры эффективно угадывают , какой тип поведения кэширования наиболее целесообразен для данного типа контента. Скорее всего, вам нужен больший контроль, чем он предлагает, поэтому вам придется потратить время на настройку заголовков ответов.

Какие значения заголовка ответа следует использовать?

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

Долговременное кэширование для версионных URL-адресов.

Как версионные URL-адреса могут помочь вашей стратегии кэширования

Версионные URL-адреса являются хорошей практикой, поскольку они упрощают признание недействительными кэшированных ответов.

Предположим, ваш сервер инструктирует браузеры кэшировать файл CSS на 1 год ( Cache-Control: max-age=31536000 ), но ваш дизайнер только что сделал экстренное обновление, которое вам необходимо внедрить немедленно. Как уведомить браузеры об обновлении «устаревшей» кэшированной копии файла? Вы не можете, по крайней мере, без изменения URL-адреса ресурса.

После того, как браузер кэширует ответ, кешированная версия используется до тех пор, пока она не перестанет быть свежей, как это определяется max-age или expires , или пока она не будет удалена из кеша по какой-либо другой причине, например, когда пользователь очистит кеш браузера. В результате разные пользователи могут загружать разные версии файла при создании страницы: пользователи, которые только что получили ресурс, используют новую версию, а пользователи, которые кэшировали более раннюю (но все еще действительную) копию, используют более старую версию.

Чтобы получить как кэширование на стороне клиента, так и быстрые обновления, вы можете изменить URL-адрес ресурса и заставить пользователя загружать новый ответ при каждом изменении его содержимого. Обычно это делается путем внедрения отпечатка файла или номера версии в его имя: например, style.x234dff.css .

При ответе на запросы URL-адресов, которые содержат « отпечаток пальца » или информацию о версии и чье содержимое никогда не должно меняться, добавьте в свои ответы Cache-Control: max-age=31536000 .

Установка этого значения сообщает браузеру, что когда ему потребуется загрузить один и тот же URL-адрес в любое время в течение следующего года (31 536 000 секунд, максимальное поддерживаемое значение), он может немедленно использовать значение в HTTP-кэше без необходимости делать сетевой запрос к вашему веб-сервер вообще. Это здорово — вы сразу же получаете надежность и скорость, обеспечиваемые отсутствием сети!

Инструменты сборки, такие как Webpack, могут автоматизировать процесс присвоения хэш-отпечатков URL-адресам ваших ресурсов.

Примечание. Вы также можете добавить свойство immutable в заголовок Cache-Control в качестве дополнительной оптимизации, хотя некоторые браузеры игнорируют его .

Повторная проверка сервера для неверсионных URL-адресов

К сожалению, не все загружаемые вами URL-адреса имеют версии. Возможно, вы не можете включить этап сборки перед развертыванием веб-приложения, поэтому вы не можете добавлять хэши к URL-адресам своих ресурсов. И каждому веб-приложению нужны HTML-файлы, которые почти никогда не содержат информацию о версии, потому что никто не будет использовать ваше веб-приложение, если им нужно запомнить, что URL-адрес для посещения — https://example.com/index.34def12.html . Итак, что вы можете сделать для этих URL-адресов?

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

Следующие значения Cache-Control помогут вам точно настроить, где и как кэшируются неверсионные URL-адреса:

• no-cache сообщает браузеру, что он должен проходить повторную проверку на сервере каждый раз, прежде чем использовать кэшированную версию URL-адреса.
• no-store сообщает браузеру и другим промежуточным кэшам (например, CDN) никогда не сохранять какую-либо версию файла.
• private : Браузеры могут кэшировать файл, но промежуточные кэши — нет.
• public : ответ может храниться в любом кеше.

См. Приложение: блок-схема Cache-Control , чтобы визуализировать процесс принятия решения о том, какие значения Cache-Control использовать. Cache-Control также может принимать список директив, разделенных запятыми. См. Приложение: Примеры Cache-Control .

Также может помочь установка ETag или Last-Modified . Как упоминалось в заголовках ответов , ETag и Last-Modified служат одной и той же цели: определить, нужно ли браузеру повторно загружать кэшированный файл, срок действия которого истек. Мы рекомендуем использовать ETag поскольку он более точен.

Пример ETag

Предположим, что с момента первоначальной выборки прошло 120 секунд, и браузер инициировал новый запрос того же ресурса. Сначала браузер проверяет HTTP-кеш и находит предыдущий ответ. К сожалению, браузер не может использовать предыдущий ответ, поскольку срок его действия истек. На этом этапе браузер может отправить новый запрос и получить новый полный ответ. Однако это неэффективно, поскольку, если ресурс не изменился, нет смысла повторно загружать информацию, которая уже находится в кеше.
Это проблема, для решения которой предназначены токены проверки ETag . Сервер генерирует и возвращает произвольный токен, который обычно представляет собой хэш или какой-либо другой отпечаток содержимого файла. Браузеру не обязательно знать, как генерируется отпечаток пальца. Ему нужно только отправить его на сервер при следующем запросе. Если отпечаток остался прежним, значит ресурс не изменился и браузер может пропустить загрузку.

Установка ETag или Last-Modified делает запрос на повторную проверку намного более эффективным, позволяя ему запускать заголовки запроса If-Modified-Since или If-None-Match упомянутые в Заголовки запроса .

Когда правильно настроенный веб-сервер видит эти заголовки входящих запросов, он может подтвердить, соответствует ли версия ресурса, который браузер уже имеет в своем HTTP-кеше, последней версии на веб-сервере. Если есть совпадение, сервер может ответить HTTP-ответом 304 Not Modified , что эквивалентно «Эй, продолжай использовать то, что у тебя уже есть!» При отправке такого типа ответа требуется передать очень мало данных, поэтому обычно это намного быстрее, чем фактическая отправка обратно копии фактического запрошенного ресурса.

Браузер запрашивает /file с сервера и включает заголовок If-None-Match чтобы указать серверу возвращать полный файл только в том случае, если ETag файла на сервере не соответствует значению If-None-Match браузера. В этом случае значения совпадают, поэтому сервер возвращает ответ 304 Not Modified с инструкциями о том, как долго файл следует кэшировать ( Cache-Control: max-age=120 ).

Краткое содержание

HTTP-кэш — это эффективный способ повысить производительность нагрузки, поскольку он уменьшает ненужные сетевые запросы. Он поддерживается во всех браузерах и не требует особых усилий для настройки.

Следующие конфигурации Cache-Control являются хорошим началом:

• Cache-Control: no-cache для ресурсов, которые необходимо проверять на сервере перед каждым использованием.
• Cache-Control: no-store для ресурсов, которые никогда не следует кэшировать.
• Cache-Control: max-age=31536000 для ресурсов с поддержкой версий.

Заголовок ETag или Last-Modified может помочь вам более эффективно повторно проверять ресурсы кэша с истекшим сроком действия.

Попробуйте: попробуйте кодовую лабораторию HTTP Cache , чтобы попрактиковаться в использовании Cache-Control и ETag в Express.

Узнать больше

Если вы хотите выйти за рамки основ использования заголовка Cache-Control , ознакомьтесь с рекомендациями Джейка Арчибальда по кэшированию и руководством по ошибкам максимального возраста .

См. раздел «Любите свой кэш» , чтобы узнать, как оптимизировать использование кэша для повторных посетителей.

Приложение: Дополнительные советы

Если у вас есть больше времени, вот еще способы оптимизировать использование HTTP-кеша:

• Используйте согласованные URL-адреса. Если вы размещаете один и тот же контент по разным URL-адресам, браузер извлекает и сохраняет этот контент несколько раз.
• Минимизируйте отток клиентов. Если часть ресурса (например, файл CSS) обновляется часто, а остальная часть файла — нет (как в случае с кодом библиотеки), рассмотрите возможность разделения часто обновляемого кода в отдельный файл и использования стратегии краткосрочного кэширования для часто обновляемый код и стратегия длительного кэширования для кода, который не меняется часто.
• Если некоторая степень устаревания допустима в вашей политике Cache-Control , рассмотрите новую директиву stale-while-revalidate .

Приложение. Cache-Control

Процесс принятия решения по настройке заголовков Cache-Control .

Приложение: примеры Cache-Control

Значение Cache-Control	Объяснение
max-age=86400	Ответ может кэшироваться браузерами и промежуточными кэшами на срок до одного дня (60 секунд x 60 минут x 24 часа).
private, max-age=600	Ответ может кэшироваться браузером, но не промежуточным кэшем, на срок до десяти минут (60 секунд x 10 минут).
public, max-age=31536000	Ответ может храниться в любом кэше в течение одного года.
no-store	Ответ не может быть кэширован и должен быть получен полностью при каждом запросе.