Содержание

Cache-Control — HTTP | MDN

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

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

Инструкции кеширования для запросов

Стандартные инструкции Cache-Control, которые могут задаваться клиентом для HTTP запроса.

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

Инструкции кеширования для ответов

Стандартные инструкции Cache-Control, которые могут задаваться сервером для HTTP ответа.

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

Расширенные инструкции 

Cache-Control

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

Cache-Control: immutable
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>

Управление кешированием

public
Указывает, что ответ может быть закеширован в любом кеше.
private
Указывает, что ответ предназначен для одного пользователя и не должен помещаться в разделяемый кеш. Частный кеш может хранить ресурс.
no-cache
Указывает на необходимость отправить запрос на сервер для валидации ресурса перед использованием закешированных данных.
only-if-cached
Указывает на необходимость использования только закешированных данных. Запрос на сервер не должен посылаться.

Управление временем жизни

max-age=<seconds>
Задаёт максимальное время в течение которого ресурс будет считаться актуальным. В отличие от Expires, данная инструкция является относительной по отношению ко времени запроса.
s-maxage=<seconds>
Переопределяет max-age или заголовок Expires, но применяется только для разделяемых кешей (например, прокси) и игнорируется частными кешами.
max-stale[=<seconds>]
Указывает, что клиент хочет получить ответ, для которого было превышено время устаревания. Дополнительно может быть указано значение в секундах, указывающее, что ответ не должен быть просрочен более чем на указанное значение.
min-fresh=<seconds>
Указывает, что клиент хочет получить ответ, который будет актуален как минимум указанное количество секунд.
stale-while-revalidate=<seconds>
Указывает, что клиент хочет получить просроченный ответ, одновременно осуществляя фоновую проверку наличия свежих данных. Значение в секундах обозначает, какое время клиент желает получать просроченный ответ.
stale-if-error=<seconds>

Управление ревалидацией и перезагрузкой

must-revalidate
Кеш должен проверить статус устаревших ресурсов перед их использованием. Просроченные ресурсы не должны быть использованы.
proxy-revalidate
То же самое, что must-revalidate, но применимо только к разделяемым кешам (например, прокси) и игнорируется частными кешами.
immutable
Indicates that the response body will not change over time. The resource, if unexpired, is unchanged on the server and therefore the client should not send a conditional revalidation for it (e. g. If-None-Match or If-Modified-Since) to check for updates, even when the user explicitly refreshes the page. Clients that aren’t aware of this extension must ignore them as per the HTTP specification. In Firefox,
immutable
is only honored on https:// transactions. For more information, see also this blog post.

Другие инструкции

no-store
Кеш не должен хранить никакую информацию о запросе и ответе
no-transform
Никакие преобразования не должны применяться к ресурсу. Заголовки Content-Encoding, Content-Range, Content-Type не должны изменяться прокси. Непрозрачный прокси может, например, конвертировать изображения из одного формата в другой для сохранения дискового пространства или уменьшения трафика. Инструкция 
no-transform
 запрещает это.

Выключение кеширования

Для выключения кеширования возможно добавить следующий заголовок к ответу.  Дополнительно см. заголовки Expires и Pragma.

Cache-Control: no-cache, no-store, must-revalidate

Кеширование статического контента

Для файлов, которые не будут изменяться обычно возможно применить агрессивное кеширование, отослав ответ с заголовком ниже. Например, такой ответ может быть послан для изображений, файлов CSS и JavaScript. Дополнительно см. заголовок 

Expires.

Cache-Control: public, max-age=31536000
SpecificationTitle
RFC 7234Hypertext Transfer Protocol (HTTP/1.1): Caching
RFC 5861HTTP Cache-Control Extensions for Stale Content
RFC 8246HTTP Immutable Responses

BCD tables only load in the browser

Модуль ngx_http_headers_module

Модуль ngx_http_headers_module

Модуль ngx_http_headers_module позволяет выдавать поля заголовка “Expires” и “Cache-Control”, а также добавлять произвольные поля в заголовок ответа.

Пример конфигурации
expires    24h;
expires    modified +24h;
expires    @24h;
expires    0;
expires    -1;
expires    epoch;
expires    $expires;
add_header Cache-Control private;
Директивы
Синтаксис: add_header имя значение [always];
Умолчание:
Контекст: http, server, location, if в location

Добавляет указанное поле в заголовок ответа при условии, что код ответа равен 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307 (1. 1.16, 1.0.13) или 308 (1.13.0). В значении параметра можно использовать переменные.

Директив add_header может быть несколько. Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы

add_header.

Если указан параметр always (1.7.5), то поле заголовка будет добавлено независимо от кода ответа.

Синтаксис: add_trailer имя значение [always];
Умолчание:
Контекст: http, server, location, if в location

Эта директива появилась в версии 1. 13.2.

Добавляет указанное поле в конец ответа при условии, что код ответа равен 200, 201, 206, 301, 302, 303, 307 или 308. В значении можно использовать переменные.

Директив add_trailer может быть несколько. Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы add_trailer.

Если указан параметр always, то указанное поле будет добавлено независимо от кода ответа.

Синтаксис: expires [modified] время;
expires epoch | max | off;
Умолчание:
expires off;
Контекст: http, server, location, if в location

Разрешает или запрещает добавлять или менять поля “Expires” и “Cache-Control” в заголовке ответа при условии, что код ответа равен 200, 201 (1. 3.10), 204, 206, 301, 302, 303, 304, 307 (1.1.16, 1.0.13) или 308 (1.13.0). В качестве параметра можно задать положительное или отрицательное время.

Время в поле “Expires” получается как сумма текущего времени и времени, заданного в директиве. Если используется параметр modified (0.7.0, 0.6.32), то время получается как сумма времени модификации файла и времени, заданного в директиве.

Кроме того, с помощью префикса “@” можно задать время суток (0.7.9, 0.6.34):

expires @15h40m;

Содержимое поля “Cache-Control” зависит от знака заданного времени:

  • отрицательное время — “Cache-Control: no-cache”.
  • положительное или равное нулю время — “Cache-Control: max-age=t”, где t это время в секундах, заданное в директиве.

Параметр epoch задаёт время “Thu, 01 Jan 1970 00:00:01 GMT” (1 января 1970 00:00:01 GMT) для поля “Expires” и “no-cache” для поля “Cache-Control”.

Параметр max задаёт время “Thu, 31 Dec 2037 23:55:55 GMT” (31 декабря 2037 23:55:55 GMT) для поля “Expires” и 10 лет для поля “Cache-Control”.

Параметр off запрещает добавлять или менять поля “Expires” и “Cache-Control” в заголовке ответа.

В значении последнего параметра можно использовать переменные (1.7.9):

map $sent_http_content_type $expires {
    default         off;
    application/pdf 42d;
    ~image/         max;
}

expires $expires;

В чем разница между Cache-Control: max-age=0 и no-cache?

Кстати, стоит отметить, что некоторые мобильные устройства, особенно продукты Apple, такие как iPhone/iPad, полностью игнорируют заголовки типа no-cache, no-store, Expires: 0 или что-то еще, что вы можете попытаться заставить их не использовать повторно просроченные страницы форм.

Это вызвало у нас бесконечные головные боли, когда мы пытаемся решить проблему iPad пользователя, скажем, оставленного спящим на странице, которую он достиг через процесс формы, скажем, Шаг 2 из 3, а затем устройство полностью игнорирует директивы хранилища / кэша, и, насколько я могу судить, скажите, просто берет то, что является виртуальным снимком страницы из ее последнего состояния, то есть игнорирует то, что было сказано явно, и, кроме того, берет страницу, которая не должна храниться, и сохраняет ее без фактической проверки ее снова, что приводит ко всем видам странных проблем сеанса, среди прочего.

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

Я провел довольно обширное тестирование отладчика с этой проблемой, и вот мой вывод: устройства полностью игнорируют эти директивы.

Даже при регулярном использовании я обнаружил, что некоторые мобильные телефоны также полностью не проверяют наличие новых версий, скажем, Expires: 0, а затем проверяют последние измененные даты, чтобы определить, должен ли он получить новую.

Этого просто не происходит, поэтому я был вынужден добавить строки запроса к файлам css/js, которые мне нужны для принудительного обновления, что обманывает глупые мобильные устройства, заставляя их думать, что это файл, которого у них нет, например: my.css?v=1, затем v=2 для обновления css/js. Это в значительной степени работает.

Пользовательские браузеры также, кстати, если оставить их по умолчанию, начиная с 2016 года, как я постоянно обнаруживаю (мы делаем LOT изменений и обновлений на нашем сайте), также не проверяют даты последних изменений в таких файлах, но метод строки запроса исправляет эту проблему. Это то, что я заметил с клиентами и офисными людьми, которые, как правило, используют базовые обычные пользовательские значения по умолчанию в своих браузерах и не знают о проблемах кэширования с css/js и т. д., Почти всегда не получают новый css/js при изменении, что означает, что значения по умолчанию для их браузеров, в основном MSIE / Firefox, не делают того, что им говорят, они игнорируют изменения и игнорируют последние измененные даты и не проверяют, даже если Expires: 0 установлен явно.

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

Заголовки кэша HTTP

— Полное руководство

Автор: Коди Арсено

Опубликовано 24 мая 2018 г.

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

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

1.

Cache-Control

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

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

  Cache-Control: частный, max-age = 0, без кеша
  

Эти настройки называются директивами ответа.Это следующие:

общедоступный vs частный

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

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

no-cache и no-store

no-cache показывает, что возвращенные ответы не могут использоваться для последующих запросов к тому же URL-адресу перед проверкой, изменились ли ответы сервера. Если в результате присутствует соответствующий ETag (токен проверки), no-cache выполняет двусторонний обход для проверки кэшированных ответов. Однако кеши могут исключить загрузки, если ресурсы не изменились.Другими словами, веб-браузеры могут кэшировать ресурсы, но они должны проверять при каждом запросе, изменились ли ресурсы (ответ 304, если ничего не изменилось).

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

max-age

Директива max-age устанавливает максимальное количество времени в секундах, в течение которого полученные ответы могут использоваться снова (с момента выполнения запроса). Например, max-age = 90 указывает, что актив можно повторно использовать (остается в кеше браузера) в течение следующих 90 секунд.

s-maxage

«s-» означает общий как общий кеш. Эта директива явно предназначена для CDN среди других промежуточных кешей.Эта директива переопределяет директиву max-age и истекает срок действия поля заголовка, если он присутствует. KeyCDN также подчиняется этой директиве.

must-revalidate

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

proxy-revalidate

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

no-transform

Директива no-transform предписывает любому посреднику, например прокси-серверу или кэш-серверу, не вносить никаких изменений в исходный актив. Заголовки Content-Encoding , Content-Range и Content-Type должны оставаться неизменными. Это может произойти, если непрозрачный прокси-сервер решит внести изменения в активы для экономии места. Однако это может вызвать серьезные проблемы в том случае, если актив должен оставаться идентичным исходному телу объекта, хотя также должен проходить через прокси.

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

Заголовок Cache-Control определен как часть спецификаций HTTP / 1.1 и заменяет предыдущие заголовки (например, Expires ), используемые для определения политик кэширования ответов. Cache-Control поддерживается всеми современными браузерами, так что это все, что нам нужно.

2.

Pragma

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

3.

Истекает

Пару лет назад это был основной способ указать, когда истекает срок действия активов. Expires — это просто базовая метка даты и времени. Это довольно полезно для старых пользовательских агентов, которые все еще бродят по неизведанным территориям. Однако важно отметить, что заголовки Cache-Control , max-age и s-maxage по-прежнему имеют приоритет в большинстве современных систем.Однако рекомендуется устанавливать здесь совпадающие значения для совместимости. Также важно убедиться, что вы правильно отформатировали дату, иначе она может считаться просроченной.

  Истекает: вс, 03 мая 2015 23:02:37 GMT
  

Во избежание нарушения спецификации не устанавливайте значение даты более года.

4. Валидаторы

ETag

Этот тип токена проверки (стандарт в HTTP / 1.1):

  • Передается через HTTP-заголовок ETag (сервером).
  • Обеспечивает эффективное обновление ресурсов, при котором данные не передаются, если ресурс не изменяется.

Это проиллюстрировано на следующем примере. Через 90 секунд после первоначальной выборки актива запускает в браузере новый запрос (точно такой же актив). Браузер просматривает локальный кеш и находит ранее кэшированный ответ, но не может его использовать, потому что срок его действия истек. Это момент, когда браузер запрашивает полный контент с сервера. Проблема в том, что если ресурс не изменился, нет абсолютно никаких причин для загрузки того же актива, который уже находится в кеше CDN.

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

Веб-браузер автоматически предоставляет токен ETag в заголовке HTTP-запроса If-None-Match .Затем сервер проверяет токены на соответствие текущим активам в кеше. Ответ 304 Not Modified сообщит браузеру, что актив в кэше не был изменен, и, следовательно, разрешит обновление еще на 90 секунд. Важно отметить, что эти ресурсы не нужно загружать повторно, что экономит пропускную способность и время .

Как веб-разработчики получают выгоду от эффективной повторной валидации?

Браузеры выполняют большую часть (если не) всю работу веб-разработчиков. Например, они автоматически определяют, были ли ранее указаны токены проверки, и добавляют их к исходящим запросам и обновляют временные метки кеша по мере необходимости на основе ответов от серверов.Таким образом, веб-разработчикам остается только одна работа — обеспечение серверов необходимыми токенами ETag . Пограничные серверы KeyCDN полностью поддерживают заголовок ETag .

Last-Modified

Заголовок Last-Modified указывает время последнего изменения документа, которое является наиболее распространенным средством проверки. Его можно рассматривать как устаревший валидатор со времен HTTP / 1.0. Когда в кэше хранится актив, включающий заголовок Last-Modified , он может использовать его для запроса сервера, изменилось ли это представление с течением времени (с момента последнего просмотра).Это можно сделать с помощью поля заголовка запроса If-Modified-Since .

Исходный сервер HTTP / 1.1 должен отправлять как значение ETag , так и значение Last-Modified . Более подробную информацию можно найти в разделе 13.3.4 в RFC2616.

Пример заголовка ответа KeyCDN:

  HTTP / 1.1 200 OK
Сервер: keycdn-engine
Дата: Пн, 27 апреля 2015 г., 18:54:37 GMT
Тип содержимого: текст / CSS
Длина содержимого: 44660
Подключение: keep-alive
Vary: Accept-Encoding
** Последнее изменение: понедельник, 8 декабря 2014 г., 19:23:51 GMT **
** ETag: "5485fac7-ae74" **
** Cache-Control: max-age = 533280 **
** Истекает: вс, 03 мая 2015 23:02:37 GMT **
X-Cache: HIT
X-Edge-Location: defr
Доступ-Контроль-Разрешить-Происхождение: *
Accept-Ranges: байты
  

Вы можете проверить заголовки HTTP-кэша с помощью инструмента KeyCDN HTTP Header Checker.

5. Расширение

Директивы Cache-Control

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

неизменяемый

Условная повторная проверка не запускается, даже если пользователь явно обновляет страницу. Директива immutable сообщает клиенту, что тело ответа не изменится со временем, поэтому нет необходимости проверять наличие обновлений, пока оно не истекло.

stale-while-revalidate

Директива stale-while-revalidate позволяет обслуживать устаревший актив, пока он повторно проверяется в фоновом режиме.

Значение stale-while-revalidate определено, чтобы сообщить кэшу, что у него есть определенное количество времени для проверки ресурса в фоновом режиме, продолжая доставлять устаревший. Пример этого может выглядеть следующим образом:

  Cache-Control: max-age = 2592000, stale-while-revalidate = 86400
  

Узнайте больше о директиве stale-while-revalidate в наших stale-while-revalidate и stale-if-error guide .

stale-if-error

Директива stale-if-error очень похожа на директиву stale-while-revalidate в том, что она обслуживает устаревшее содержимое по истечении срока действия max-age . Однако stale-if-error возвращает устаревшее содержимое только в том случае, если исходный сервер возвращает код ошибки (например, 500 , 502 , 503 или 504 ), когда кэш пытается повторно проверить ресурс.

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

Узнайте больше о директиве stale-if-error в наших руководствах stale-while-revalidate и stale-if-error .

Заголовки кэша KeyCDN и HTTP

KeyCDN позволяет определять заголовки кэша HTTP по своему усмотрению. Возможность устанавливать значения Expire и Max Expire непосредственно на панели управления упрощает настройку на стороне CDN.

Кроме того, если вы предпочитаете еще больший контроль над заголовками HTTP-кеша, вы можете отключить функцию «Игнорировать управление кешем» в настройках Зоны, и KeyCDN будет учитывать все заголовки вашего кеша из источника. Это очень полезно в том случае, если вам нужно исключить определенный актив или группу активов из CDN.

TL; DR

Cache-Control (в частности) вместе с полем заголовка ETag — это современные механизмы для контроля актуальности и действительности ваших активов.Остальные значения используются только для обратной совместимости.

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

Управление кешем — HTTP | MDN

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

Директивы кэширования

имеют следующие правила, чтобы быть действительными:

  • Без учета регистра, рекомендуется строчная буква.
  • Несколько директив разделяются запятыми.
  • Некоторые директивы имеют необязательный аргумент, который может быть либо токеном , либо строкой в ​​кавычках . (Определения см. В спецификации)

Директивы запроса кэша

Стандартные Директивы Cache-Control , которые могут использоваться клиентом в HTTP-запросе.

  Cache-Control: max-age = <секунды>
Cache-Control: max-stale [= <секунды>]
Cache-Control: min-fresh = <секунды>
Cache-Control: без кеширования
Cache-Control: без магазина
Cache-Control: без преобразования
Cache-Control: только при кешировании
  

Директивы ответа кэша

Стандартные директивы Cache-Control , которые могут использоваться сервером в ответе HTTP.

  Cache-Control: необходимо перепроверить
Cache-Control: без кеширования
Cache-Control: без магазина
Cache-Control: без преобразования
Cache-Control: общедоступный
Cache-Control: частный
Cache-Control: прокси-повторная валидация
Cache-Control: max-age = <секунды>
Cache-Control: s-maxage = <секунды>
  

Директивы Extension Cache-Control

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

  Cache-Control: неизменяемый
Cache-Control: stale-while-revalidate = <секунды>
Cache-Control: stale-if-error = <секунды>
  

Кэшируемость

Директивы, которые определяют, можно ли кэшировать ответ / запрос, где он может быть кэширован, и должен ли он быть подтвержден исходным сервером перед кэшированием.

общественный
Ответ может быть сохранен в любом кэше , даже если ответ обычно не кэшируется.
частный
Ответ может быть сохранен только в кэше браузера , даже если ответ обычно не кэшируется. Если вы хотите не хранить ответ в каком-либо кэше, используйте вместо него no-store . Эта директива не защищает кеш от хранения вашего ответа.
без кеширования
Ответ может быть сохранен в любом кэше , даже если ответ обычно не кэшируется.Однако сохраненный ответ ДОЛЖЕН всегда проходить проверку на исходном сервере перед его использованием, поэтому вы не можете использовать без кеша вместе с неизменяемым . Если вы хотите не хранить ответ в каком-либо кэше, используйте вместо него no-store . Эта директива не защищает кеш от хранения вашего ответа.
без магазина
Ответ может не быть сохранен в любом кэше .Обратите внимание, что это не помешает возврату действительного ранее существовавшего кешированного ответа . Клиенты могут установить max-age = 0 , чтобы также очистить существующие ответы кеша, поскольку это заставляет кеш-память повторно проверяться на сервере (никакие другие директивы не действуют при использовании с no-store ).

Срок действия

max-age =
Максимальное время, в течение которого ресурс считается свежим. В отличие от Expires , эта директива относится ко времени запроса.
s-maxage = <секунды>
Переопределяет max-age или заголовок Expires , но только для общих кешей (например, прокси). Игнорируется частными кешами.
макс. Устаревшее [= <секунды>]
Указывает, что клиент примет устаревший ответ. Необязательное значение в секундах указывает верхний предел устаревания, который примет клиент.
min-fresh = <секунды>
Указывает, что клиент хочет получить ответ, который будет актуальным в течение по крайней мере указанного количества секунд.
stale-while-revalidate = <секунды>
Указывает, что клиент примет устаревший ответ при асинхронной проверке в фоновом режиме нового ответа. Значение секунд указывает, как долго клиент будет принимать устаревший ответ. Обратите внимание, что отсчет времени начинается не во время самого запроса, а, например, по истечении max-age . См. «Сохранение актуальности с помощью stale-while-revalidate » для получения дополнительной информации.
stale-if-error = <секунды>
Указывает, что клиент примет устаревший ответ, если проверка нового ответа не удалась. Значение секунд указывает, как долго клиент будет принимать устаревший ответ после первоначального истечения срока действия.

Повторная валидация и повторная загрузка

обязательная повторная валидация
Указывает, что как только ресурс становится устаревшим, кеши не должны использовать свою устаревшую копию без успешной проверки на исходном сервере.
перепроверить прокси
Как необходимо повторно проверить, но только для общих кешей (например, прокси). Игнорируется частными кешами.
неизменяемый
Указывает, что тело ответа не изменится со временем на . Ресурс, если не истек , не изменяется на сервере, и поэтому клиент не должен отправлять для него условную повторную проверку (например, If-None-Match или If-Modified-Since ) для проверки обновлений, даже если пользователь явно обновляет страницу.Клиенты, которые не знают об этом расширении, должны игнорировать их в соответствии со спецификацией HTTP. В Firefox неизменяемый обрабатывается только для транзакций https: // . Для получения дополнительной информации см. Также это сообщение в блоге.

Другое

без преобразования
Промежуточный кэш или прокси-сервер не может редактировать тело ответа, Content-Encoding , Content-Range или Content-Type . Поэтому он запрещает прокси-серверу или функции браузера, такой как Google Web Light, преобразовывать изображения, чтобы минимизировать объем данных для кеш-хранилища или медленного соединения.
только при кэшировании
Устанавливается клиентом для указания «не использовать сеть» для ответа. Кэш должен либо ответить, используя сохраненный ответ, либо ответить кодом состояния 504 . Условные заголовки, такие как If-None-Match , устанавливать не следует. Нет никакого эффекта, если только если кэшируется установлен сервером как часть ответа.

Предотвращение кеширования

Чтобы отключить кеширование ресурса, вы можете отправить следующий заголовок ответа:

Хорошо:

Директива no-store предотвратит кэширование нового ресурса, но не предотвратит ответ кеша нестандартным ресурсом, который был кэширован в результате более раннего запроса.Установка max-age = 0 также приводит к повторной проверке кеша (очищает кеш).

  Cache-Control: no-store, max-age = 0
  
Плохо:
  частный, без кеширования, без хранения, max-age = 0, обязательная повторная проверка, предварительная проверка = 0, пост-проверка = 0  

Кэширование статических ресурсов

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

  общедоступный, max-age = 604800, неизменяемый
  

Требуется повторная проверка

no-cache и max-age = 0, значение must-revalidate указывает на то же значение.
Клиенты могут кэшировать ресурс, но должны каждый раз проверять его перед использованием. Это означает, что HTTP-запрос выполняется каждый раз, хотя он может пропустить загрузку тела HTTP, если контент действителен.

  max-age = 0, требуется повторная валидация  

Примечание : Следующее может служить устаревшим ресурсом, если сервер не работает или теряет связь.

Таблицы BCD загружаются только в браузере

Что такое Cache-Control и как работают заголовки HTTP-кэша | Руководство CDN

Что такое заголовок Cache-Control

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

Заголовок управления кешем разбит на директивы, наиболее распространенные из которых подробно описаны ниже:

Пример заголовка ответа HTTP от google.com

Cache-Control: Max-Age

Директива запроса max-age определяет в секундах время, необходимое для истечения срока действия кэшированной копии ресурса. По истечении срока действия браузер должен обновить свою версию ресурса, отправив другой запрос на сервер.

Например, cache-control: max-age = 120 означает, что возвращенный ресурс действителен в течение 120 секунд, после чего браузер должен запросить более новую версию.

Контроль кэша: без кэша

Директива no-cache означает, что браузер может кэшировать ответ, но сначала должен отправить запрос проверки на исходный сервер.

Контроль кэша: без магазина

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

Cache-Control: общедоступный

Директива публичного ответа указывает, что ресурс может кэшироваться любым кешем.

Cache-Control: частный

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

Дополнительные заголовки кэша HTTP

Помимо управления кешем, известные заголовки HTTP-кеша включают:

  • Истекает — Этот заголовок указывает фиксированную дату / время истечения срока действия кэшированного ресурса. Например, Expires: Sat, 13 May 2017 07:00:00 GMT сигнализирует, что срок действия кэшированного ресурса истекает 13 мая 2017 года в 7:00 утра по Гринвичу. Заголовок expires игнорируется, если присутствует заголовок управления кешем, содержащий директиву max-age.
  • ETag — Заголовок ответа, который определяет версию обслуживаемого контента в соответствии с токеном — строкой символов в кавычках, например.g., "675af34563dc-tr34" — который изменяется после изменения ресурса. Если токен не изменился до того, как был сделан запрос, браузер продолжит использовать свою локальную версию.
  • Vary — Заголовок, определяющий ответы, которые должны соответствовать кэшированному ресурсу, чтобы он считался действительным. Например, заголовок Vary: Accept-Language, User-Agent указывает, что кешированная версия должна существовать для каждой комбинации пользовательского агента и языка.

Узнайте, как Imperva CDN может помочь вам повысить производительность веб-сайта.

CDN и Cache-Control

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

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

Наконец, более продвинутые сети CDN используют передовые методы автоматизации, включая машинное обучение, для кэширования динамически генерируемого контента и ресурсов. Это оптимизирует ваши политики кэширования и еще больше ускоряет доставку контента.

Лучшие практики кэширования и ошибки максимального возраста

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

Подавляющее большинство передовых методов кэширования можно разделить на два шаблона:

Паттерн 1: неизменяемый контент + long max-age

 Cache-Control: max-age = 31536000 
  • Содержимое по этому URL-адресу никогда не изменяется, поэтому…
  • Браузер / CDN может без проблем кэшировать этот ресурс на год
  • Кэшированный контент младше макс. Возраст секунд можно использовать без консультации с сервером

Страница: Привет, мне нужен «/ script-v1.js «,» /styles-v1.css «и» /cats-v1.jpg » 10:24

Кэш: Я получил ничего, как насчет тебя, Сервер? 10:24

Сервер: Конечно, держи. Btw Cache: их можно использовать примерно год. 10:25

Кэш: Спасибо! 10:25

Страница: Ваше здоровье! 10:25

На следующий день

Страница: Привет, мне нужны «/ script- v2 .js», «/ styles- v2 .css» и «/ cats-v1.jpg » 8:14

Кэш: У меня есть кошачья, вот и все. Других у меня нет. Сервер? 8:14

Сервер: Конечно, вот новые CSS и JS. Btw Cache: их тоже можно использовать в течение года. 8:15

Кэш: Блестяще! 8:15

Страница: Спасибо! 8:15

Позднее

Кэш: Хм, я какое-то время не использовал «/script-v1.js» и «/styles-v1.css».Я их просто удалю. 12:32

В этом шаблоне вы никогда не изменяете контент по определенному URL-адресу, вы меняете URL-адрес:

  

…  

Каждый URL-адрес содержит что-то, что изменяется вместе с его содержанием. Это может быть номер версии, дата изменения или хеш содержимого — именно этим я и занимаюсь в этом блоге.

Большинство серверных фреймворков поставляются с инструментами, упрощающими эту задачу (я использую Django ManifestStaticFilesStorage ), и есть небольшие библиотеки Node.js, которые достигают того же, например gulp-rev.

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

Паттерн 2: изменяемый контент, всегда проверяется сервером

  • Содержимое этого URL может измениться, поэтому…
  • Любая версия, сохраненная в локальном кэше, не заслуживает доверия без согласия сервера

Страница: Привет, мне нужен контент для «/ about /» и «/sw.js» 11:32

Кэш: Я не могу тебе помочь. Сервер? 11:32

Сервер: Да, они у меня есть, вот и все. Кэш: вы можете хранить их, но не используйте их, не спросив.11:33

Кэш: Конечно! 11:33

Страница: Спасибо! 11:33

На следующий день

Страница: Привет, мне снова нужен контент для «/ about /» и «/sw.js» 09:46

Кэш: Один момент. Сервер: могу ли я использовать свои копии? Моя копия «/ about /» последний раз обновлялась в понедельник, а «/sw.js» последний раз обновлялась вчера. 09:46

Сервер: «/sw.js» с тех пор не изменился … 09:47

Кэш: Прохладный.Страница: вот «/sw.js». 09:47

Сервер: … Но у «/ about /» есть новая версия. Кэш: как и раньше, вы можете сохранить его, но не используйте его, не спросив. 09:47

Кэш: Понятно! 09:47

Страница: Отлично! 09:47

Примечание: no-cache не означает «не кэшировать», это означает, что он должен проверить (или «перепроверить», как он это называет) с сервером перед использованием кэшированного ресурса. no-store сообщает браузеру не кэшировать его вообще. Также необходимо повторно проверить. не означает «необходимо повторно проверить», это означает, что локальный ресурс может быть использован, если он младше указанного max-age , в противном случае он должен пройти повторную проверку. Ага. Я знаю.

В этом шаблоне вы можете добавить в ответ заголовок даты ETag (идентификатор версии по вашему выбору) или Last-Modified . В следующий раз, когда клиент извлекает ресурс, он повторяет значение уже имеющегося контента через If-None-Match и If-Modified-Since соответственно, позволяя серверу сказать: «Просто используйте то, что у вас уже есть. , это актуально », или, как говорится,« HTTP 304 ».

Если отправка ETag / Last-Modified невозможна, сервер всегда отправляет полное содержимое.

Этот шаблон всегда включает выборку из сети, поэтому он не так хорош, как шаблон 1, который может полностью обойти сеть.

Нередко откладывается инфраструктура, необходимая для шаблона 1, но аналогичным образом откладываются требования шаблона 2 сетевого запроса, и вместо этого выбирается что-то посередине: небольшой max-age и изменяемый контент.Это бескомпромиссный компромисс.

max-age для изменяемого контента часто является неправильным выбором

… и, к сожалению, это не редкость, например, на страницах Github.

Представьте:

  • / артикул /
  • /styles.css
  • /script.js

… все обслуживаются:

 Cache-Control: must-revalidate, max-age = 600 
  • Содержимое в URL-адресах изменяется
  • Если в браузере есть кешированная версия старше 10 минут, используйте ее без консультации с сервером
  • В противном случае выполните выборку из сети, используя If-Modified-Since или If-None-Match , если доступно

Страница: Эй, мне нужны «/ article /», «/ script.js «и» /styles.css » 10:21

Кэш: Здесь ничего нет, Сервер? 10:21

Сервер: Нет проблем, вот они. Btw Cache: их можно использовать в течение следующих 10 минут. 10:22

Кэш: Попался! 10:22

Страница: Спасибо! 10:22

6 минут спустя

Страница: Эй, мне снова нужны «/ article /», «/script.js» и «/styles.css» 10:28

Кэш: Омг, мне очень жаль, я потерял файл «/ styles.css «, но у меня есть другие, пожалуйста. Сервер: вы можете дать мне» /styles.css «? 10:28

Сервер: Конечно, это действительно изменилось с тех пор, как вы в последний раз просили об этом. Также можно использовать в течение следующих 10 минут. 10:29

Кэш: Без проблем. 10:29

Страница: Спасибо! Ждать! Все сломано !! Что происходит? 10:29

Этот паттерн может показаться работающим при тестировании, но ломается в реальном мире, и его действительно сложно отследить.В приведенном выше примере сервер действительно обновил HTML, CSS и JS, но на странице остались старые HTML и JS из кеша и обновленный CSS с сервера. Несовпадение версий сломало ситуацию.

Часто, когда мы вносим существенные изменения в HTML, мы, вероятно, также изменим CSS, чтобы отразить новую структуру, и обновить JS, чтобы учесть изменения в стиле и содержании. Эти ресурсы взаимозависимы, но заголовки кеширования не могут этого выразить. Пользователи могут получить новую версию одного / двух ресурсов, но старую версию другого (-ых).

max-age относится ко времени отклика, поэтому, если все вышеперечисленные ресурсы запрашиваются как часть одной и той же навигации, они будут истекать примерно в одно и то же время, но все еще есть небольшая вероятность гонки. . Если у вас есть страницы, которые не содержат JS или содержат другой CSS, даты истечения срока действия могут не синхронизироваться. И что еще хуже, браузер все время удаляет вещи из кеша и не знает, что HTML, CSS и JS взаимозависимы, поэтому он с радостью удалит одно, но не остальные.Умножьте все это вместе, и станет весьма вероятным, что вы можете получить несовпадающие версии этих ресурсов.

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

К счастью, для пользователя есть аварийный люк…

Обновление иногда исправляет

Если страница загружается как часть обновления, браузеры всегда будут повторно проверять достоверность на сервере, игнорируя max-age .Поэтому, если у пользователя что-то не работает из-за max-age , обновление должно все исправить. Конечно, принуждение пользователя к этому снижает доверие, так как создается впечатление, что ваш сайт темпераментный.

Сервисный работник может продлить жизнь этим багам

Допустим, у вас есть следующий обслуживающий персонал:

  const version = '2';

self.addEventListener ('установить', (событие) => {
  event.waitUntil (
    тайники
      .open (`статические - $ {версия}`)
      .затем ((cache) => cache.addAll (['/ styles.css', '/script.js'])),
  );
});

self.addEventListener ('активировать', (событие) => {
  
});

self.addEventListener ('выборка', (событие) => {
  event.respondWith (
    тайники
      .match (event.request)
      .then ((response) => response || fetch (event.request)),
  );
});  

Этот обслуживающий работник…

  • Кэширует сценарий и стили впереди
  • Обслуживает из кеша, если есть совпадение, в противном случае переходит в сеть

Если мы изменим наш CSS / JS, мы увеличим версию , чтобы служебный воркер стал другим побайтовым, что вызывает обновление.Однако, поскольку addAll выполняет выборку через кеш HTTP (как это делают почти все выборки), мы могли столкнуться с состоянием гонки max-age и несовместимыми с кешем версиями CSS и JS.

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

Вы могли обходить кеш в сервис-воркере:

  сам.addEventListener ('установить', (событие) => {
  event.waitUntil (
    тайники
      .open (`статические - $ {версия}`)
      .then ((кеш) =>
        cache.addAll ([
          новый запрос ('/ styles.css', {cache: 'no-cache'}),
          новый запрос ('/ script.js', {cache: 'no-cache'}),
        ]),
      ),
  );
});  

К сожалению, параметры кеширования еще не поддерживаются в Chrome / Opera и только недавно появились в Firefox Nightly, но вы можете вроде как сделать это самостоятельно:

  сам.addEventListener ('установить', (событие) => {
  event.waitUntil (
    caches.open (`static - $ {version}`) .then ((cache) =>
      Promise.all (
        ['/styles.css', '/script.js'] ].map((url) => {
          
          return fetch (`$ {url}? $ {Math.random ()}`) .then ((response) => {
            
            если (! response.ok) выбросить ошибку («Не в порядке»);
            вернуть cache.put (URL, ответ);
          });
        }),
      ),
    ),
  );
});  

В приведенном выше примере я перебираю кеш с помощью случайного числа, но вы можете пойти еще дальше и использовать этап сборки для добавления хэша содержимого (аналогично тому, что делает sw-precache).Это своего рода повторная реализация шаблона 1 в JavaScript, но только для пользы пользователей сервис-воркеров, а не для всех браузеров и вашего CDN.

Сервисный воркер и HTTP-кеш хорошо работают вместе, не заставляйте их драться!

Как видите, вы можете обойти плохое кеширование в сервис-воркере, но лучше исправить корень проблемы. Правильное кэширование упрощает работу с сервис-воркером, но также приносит пользу браузерам, которые не поддерживают сервис-воркер (Safari, IE / Edge), и позволяет вам максимально эффективно использовать свой CDN.

Правильные заголовки кеширования означают, что вы также можете значительно упростить обновление сервис-воркеров:

  const version = '23';

self.addEventListener ('установить', (событие) => {
  event.waitUntil (
    тайники
      .open (`статические - $ {версия}`)
      .then ((кеш) =>
        cache.addAll ([
          '/',
          '/script-f93bca2c.js',
          '/styles-a837cb1e.css',
          '/cats-0e9a2ef4.jpg',
        ]),
      ),
  );
});  

Здесь я бы кэшировал корневую страницу с использованием шаблона 2 (повторная проверка сервера), а остальные ресурсы с использованием шаблона 1 (неизменяемое содержимое).Каждое обновление сервис-воркера будет запускать запрос для корневой страницы, но остальные ресурсы будут загружены только в том случае, если их URL-адрес изменился. Это здорово, потому что это экономит пропускную способность и повышает производительность независимо от того, обновляете ли вы предыдущую версию или 10 версий назад.

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

Сервис-воркеры лучше всего работают как расширение, а не как обходной путь, поэтому вместо борьбы с кешем работайте с ним!

При осторожном использовании максимальный возраст и изменяемый контент могут быть полезны

max-age для изменяемого содержимого часто неправильный выбор, но не всегда. Например, на этой странице max-age составляет три минуты. Условия гонки здесь не проблема, потому что эта страница не имеет никаких зависимостей, которые следуют одному и тому же шаблону кеширования (мои URL-адреса CSS, JS и изображений соответствуют шаблону 1 — неизменяемое содержимое), и ничто, зависящее от этой страницы, не следует тому же шаблону.

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

Этот узор нельзя использовать легкомысленно. Если я добавлял новый раздел в одну статью и ссылался на него в другой статье, я создавал зависимость, которая могла соревноваться. Пользователь мог щелкнуть ссылку и перейти к копии статьи без указанного раздела.Если бы я хотел избежать этого, я бы обновил первую статью, сбросил кэшированную копию Cloudflare с помощью их пользовательского интерфейса, подождал три минуты, , затем добавил ссылку на нее в другой статье. Да… с этим шаблоном нужно быть очень осторожным.

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

Блог

месяцев: срок действия истекает по сравнению с максимальным возрастом

Вторник, 15 мая 2007 г.

Кеширование HTTP

Я иногда получаю вопрос от читателей руководства по кешированию о том, использовать ли заголовок Expires или Cache-Control: max-age для управления временем жизни ответа.

Некоторые люди утверждают, что Expires лучше, потому что он определяется HTTP / 1.0, тогда как Cache-Control появился только в HTTP / 1.1. Поскольку агенты HTTP / 1.0 все еще существуют, рассуждают, это более безопасный путь.

Проблема с этой цепочкой рассуждений в том, что версии HTTP не такие черно-белые; То, что что-то рекламирует себя как HTTP / 1.0, не означает, что оно не понимает HTTP / 1.1 (подробнее см. RFC2145). Фактически, поскольку Cache-Control был одним из ранних механизмов в HTTP / 1.1, практически каждая реализация кеширования понимает максимальный возраст, какую бы версию HTTP они ни рекламировали.

Итак, это уравняет двоих. Что склоняет чашу весов в пользу Cache-Control: max-age просто относительно. Рассмотрим:

Cache-Control: max-age = 3600

вместо

Истекает: Вт, 15 мая 2007 07:19:00 GMT

CC: max-age — это просто целое число секунд, а Expires имеет несколько сложный формат даты. Судя по тому, что я видел в различных реализациях, это имеет значение; даже небольшие ошибки в генерации значения Expires (например,g., опуская «0» в начале часа) может привести к неправильной интерпретации нисходящего кэша. Это случается чаще, чем вы думаете.

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

Клиенты и кеши

HTTP / 1.1 ДОЛЖНЫ обрабатывать другие недопустимые форматы даты, особенно включая значение «0», как в прошлом (т. Е. «Срок действия уже истек»).

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

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

Итак, я рекомендую либо использовать хорошо протестированную библиотеку (например, mod_expires) для генерации Expires и Cache-Control: max-age для вас, либо только генерирует CC: max-age, если вы делаете сделайте это самостоятельно, чтобы уменьшить вероятность испортить вещи.


Разработчик Akamai | S-Maxage

S-Maxage теперь в GA для Dynamic Site Accelerator и Ion ! Мы прислушались к мнению наших пользователей и создали более простой способ управления настройками кеша.

Что такое S-Maxage?

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

S-Maxage — это директива управления кешем, разработанная инженерной группой Интернета (IETF), которая значительно упрощает настройку кэширования для общих кешей — с помощью одной настройки. Для команд, использующих несколько сетей CDN, эта новая возможность значительно упрощает управление кешем.

Теперь, когда вы включите S-Maxage, вы можете решить, как долго контент будет кэшироваться, начиная с момента запроса контента CDN, настроив время жизни (TTL) только один раз для всех ваших CDN и промежуточных кешей.

Каковы преимущества?

  • Сконфигурируйте настройки кеша для всех ваших CDN одновременно

  • Замените ранее существовавшие max-age и Истекают настройки , если они присутствуют в общем кэше

  • Поддерживайте отличную производительность, поскольку ваш браузер игнорирует S-Maxage

Включив S-Maxage, вы можете легко стандартизировать TTL кэширования для различных CDN с помощью одной настройки. Это уменьшит накладные расходы на настройку для кэширования и уменьшит ненужную сложность.

С поддержкой Honor Cache-Control, если ответ включает в себя директиву S-Maxage в заголовке ответа Cache-Control для общего кеша, максимальный возраст, указанный в этой директиве, переопределяет максимальный возраст, указанный в max-age или заголовок Expires .

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

Включение поддержки S-Maxage

Включение S-Maxage — это простой трехэтапный процесс:

  1. Перейдите на страницу Property Manager в Центре управления и создайте новую конфигурацию или новую версию существующей конфигурации

  2. Выберите «Honor Origin Cache-Control» или «Honor Origin Cache-Control and Expires» из раскрывающегося списка «Вариант кэширования».

  3. Включите переключатель «Расширенная поддержка RFC».

  4. Включите переключатель «Honor s-maxage».

  5. Сохраните и активируйте версию свойства.

  6. После активации Akamai начнет соблюдать директиву «S-Maxage» в заголовке Cache-Control, отправленном источником.

Примечание. Эти параметры будут одинаковыми для создания новой конфигурации Property Manager и создания новой версии из существующей конфигурации Property Manager.

Что происходит с заголовком Edge Control?

Заголовок Edge-Control — это специальный заголовок Akamai, используемый для переопределения всех других настроек кеша, включая директиву S-Maxage, и может быть отправлен с исходного сервера.

Мы соблюдаем директиву S-Maxage только тогда, когда для кэширования Akamai установлено значение «Honor Origin Cache-Control» или «Honor Origin Cache-Control and Expires». Заголовок «Edge-Control» переопределяет TTL в конфигурации независимо от того, что настройка кеширования у нас есть в конфигурации.

Ниже вы можете увидеть пример того, как работают эти настройки кеширования:

Запрос к источнику:


Запрос через Akamai:


FAQ

  1. Будете ли вы соблюдать заголовок Edge Control по S -Максаж?
    Да, мы продолжаем соблюдать заголовок Edge Control по отношению к директиве S-Maxage, чтобы переопределить настройки TTL в конфигурации.

  2. Какой порядок приоритета?
    Порядок: Edge-Control, затем Cache-Control и Expires.

  3. Как включить S-Maxage, если у меня есть настройка Edge Cache?
    Если заказчик использует подход с несколькими CDN и решил рассмотреть S-Maxage для кэширования, чтобы поддерживать его единообразие во всех CDN, ему нужно только включить S-Maxage в поведении кэширования и удалить настройку Edge Cache.

  4. Как определяются настройки кеширования, если S-Maxage не включен?
    Если в заголовке Cache-Control нет директивы S-Maxage, мы считаем значение max-age TTL для объекта.

Вам также может понравиться

Если вы не являетесь клиентом Ion или Dynamic Site Accelerator, вы можете попробовать S-Maxage, подписавшись на бесплатную пробную версию:

Вы также можете проверить справку Property Manager по кэшированию Поведение, S-Maxage и другие директивы кеширования, чтобы узнать больше.

HTTP-кеширование | Основы Интернета | Разработчики Google

Дэйв — технический писатель

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

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

Хотя кеширование HTTP стандартизовано в соответствии с Спецификации Internet Engineering Task Force (IETF), браузеры могут иметь несколько кешей, которые различаются по способу получения, хранения и сохранения содержимого. Вы можете прочитать о том, чем отличаются эти кеши, в этой отличной статье, Повесть о четырех тайниках.

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

Включение кэширования

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

Также важно помнить, что то, что мы называем кешированием браузера, на самом деле может потребовать размещать на любой промежуточной остановке между исходным сервером и клиентским браузером, например как прокси-кеш или кеш сети доставки контента (CDN).

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

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

Кэш-контроль

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

  
 Заголовочный набор Cache-Control "max-age = 2592000, общедоступный"

  

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

  
 Заголовочный набор Cache-Control "max-age = 86400, общедоступный"

  

Cache-control имеет ряд параметров, часто называемых директивами , которые могут быть установлены на конкретно определить, как обрабатываются запросы кеша. Некоторые общие директивы: объяснено ниже; вы можете найти более подробную информацию на В разделе Оптимизация производительности и в Сеть разработчиков Mozilla.

  • no-cache : несколько неверно, указывает, что контент можно кэшировать, но если да, он должен повторно проверяться при каждом запросе перед тем, как быть обслуженным клиентом.Это заставляет клиент проверяет актуальность, но позволяет избежать повторной загрузки ресурса, если он не изменилось. Взаимоисключающий с no-store .

  • no-store : Указывает, что содержимое фактически не может быть кэшировано каким-либо образом. первичный или промежуточный кеш. Это хороший вариант для ресурсов, которые могут содержать конфиденциальные данные или ресурсы, которые почти наверняка будут меняться от посещения к посещению. Взаимно эксклюзивно с без кеширования .

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

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

  • max-age : определяет максимальное время, в течение которого контент может быть кэширован, прежде чем он должен быть перепроверена или повторно загружена с исходного сервера. Эта опция обычно заменяет истекает заголовок (см. ниже) и принимает значение в секундах с максимальным допустимым возрастом один год (31536000 секунд).

Истекает срок кеширования

Вы также можете включить кеширование, указав время истечения или истечения срока для определенных типов файлы, которые сообщают браузерам, как долго использовать кэшированный ресурс, прежде чем запрашивать новую копию с сервера.Заголовок expires просто устанавливает время в будущем, когда контент должен истек. После этого запросы контента должны возвращаться на исходный сервер. С участием более новый и более гибкий заголовок управления кешем, заголовок expires часто используется в качестве запасного варианта.

Вот пример того, как вы можете настроить кэширование в файле .htaccess на сервере Apache.

  ## СРОК КЭШИНГА ##
ExpiresActive On
ExpiresByType image / jpg «доступ плюс 1 год»
ExpiresByType image / jpeg "доступ плюс 1 год"
ExpiresByType image / gif "доступ плюс 1 год"
ExpiresByType image / png "доступ плюс 1 год"
ExpiresByType text / css "доступ плюс 1 месяц"
Приложение ExpiresByType / pdf "доступ плюс 1 месяц"
ExpiresByType text / x-javascript "доступ плюс 1 месяц"
Приложение ExpiresByType / x-shockwave-flash "доступ плюс 1 месяц"
ExpiresByType изображение / значок x "доступ плюс 1 год"
ExpiresDefault "доступ плюс 2 дня"
## СРОК КЭШЕНИЯ ##
  

(источник: GTmetrix)

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

Совет: Не используйте срок годности более одного года; это фактически навсегда в Интернете и, как отмечено выше, является максимальным значением для max-age под управлением кешем.

Сводка

Кэширование

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

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

Обратная связь

Была ли эта страница полезной?

Есть

Что было самым лучшим на этой странице?

Это помогло мне выполнить мои цели

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Там была информация, которая мне была нужна

Спасибо за ваш отзыв!Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Имеет точную информацию

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Легко читалось

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Что-то еще

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Что было хуже всего на этой странице?

Это не помогло мне выполнить мои цели

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Отсутствовала необходимая мне информация

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.

Он имел неточную информацию

Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.