Cache-control

Cache-Control configuration

The HTTP header can be implemented on the server or can even be added within the code. The following are examples of how to implement in Apache, Nginx, or within your PHP code.

Apache

The following snippet can be added to your .htaccess file to tell the server to set the header’s to seconds and to for the listed files. and headers can also be included with Apache by using the module.

Nginx

This snippet can be added to your Nginx configuration file. The example below uses the header directives and with an expire setting set to 2 days.

PHP

headers can also be added directly in your code. This example demonstrates using the PHP header to include setting a of 1 day.

Кэширование по содержанию

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

Рассмотрим пример выдачи изображения из базы данных индентифицируемых по ID. Вызов страницы выглядит следующим образом:

http://www.your.server/viewpic.php3?id=23123

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

mysql_connect("host", "user", "passwd");
$image=mysql("db", "select pics,type from pictures where id=$id");

Header("Cache-Control: public, must-revalidate");
Header("Vary: Content-ID");
Header("Content-ID: ".md5(mysql_result($image, 0, "pics")));

Header("Content-type: ".mysql_result($image, 0, "type"));

echo mysql_result($image, 0, "pics");
mysql_freeResult($image);
mysql_close();

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

Заголовки HTTP-кэширования

Есть два основных заголовка кэша: Cache-Control и Expires.

Cache-Control

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

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

Cache-Control:public

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

Cache-Control:private

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

Cache-Control:public, max-age=31536000

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

Expires

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

Если установлены Expires и max-age, значение  max-age будет иметь приоритет.

Cache-Control:public
Expires: Mon, 25 Jun 2012 21:31:12 GMT

Несколько других заголовков указывают, как извлекать ресурсы из Сети. Этот тип запросов известен как условные запросы.

Заголовки директив кэшаCache-directive headers

Важно!

По умолчанию конечная точка Azure CDN, оптимизированная для DSA, игнорирует заголовки директив кэша и обходит кэширование.By default, an Azure CDN endpoint that is optimized for DSA ignores cache-directive headers and bypasses caching. Для профилей Azure CDN уровня «Стандартный» от Verizon и Azure CDN уровня «Стандартный» от Akamai можно настроить способ обработки этих заголовков конечной точкой Azure CDN, воспользовавшись правилами кэширования CDN для включения кэширования.For Azure CDN Standard from Verizon and Azure CDN Standard from Akamai profiles, you can adjust how an Azure CDN endpoint treats these headers by using CDN caching rules to enable caching. Только для профилей Azure CDN уровня «Премиум» от Verizon для включения кэширования используется обработчик правил.For Azure CDN Premium from Verizon profiles only, you use the rules engine to enable caching.

Azure CDN поддерживает следующие заголовки директив кэша HTTP, которые определяют длительность кэширования и совместное использование кэша.Azure CDN supports the following HTTP cache-directive headers, which define cache duration and cache sharing.

Управление кэшем:Cache-Control:

  • Представлен в HTTP 1.1, чтобы дать веб-издателям больше возможностей управления своим содержимым и устранить ограничения заголовка .Introduced in HTTP 1.1 to give web publishers more control over their content and to address the limitations of the header.
  • Переопределяет заголовок , если определен этот заголовок и заголовок .Overrides the header, if both it and are defined.
  • Если указан в HTTP-запросе от клиента к POP сети CDN, все профили Azure CDN по умолчанию игнорируют его.When used in an HTTP request from the client to the CDN POP, is ignored by all Azure CDN profiles, by default.
  • При использовании в HTTP-ответе от клиента к POP CDN:When used in an HTTP response from the client to the CDN POP:
    • Azure CDN уровня «Стандартный» или «Премиум» от Verizon и Azure CDN уровня «Стандартный» от Microsoft поддерживают все директивы .Azure CDN Standard/Premium from Verizon and Azure CDN Standard from Microsoft support all directives.
    • Azure CDN уровня «Стандартный» от Akamai поддерживает перечисленные ниже директивы и игнорирует все остальные.Azure CDN Standard from Akamai supports only the following directives; all others are ignored:
      • . Содержимое может храниться в кэше в течение указанного количества секунд.: A cache can store the content for the number of seconds specified. Например, .For example, . Эта директива задает максимальное время, в течение которого содержимое будет считаться актуальным.This directive specifies the maximum amount of time the content is considered to be fresh.
      • . Кэширует содержимое, но проверяет содержимое каждый раз перед его доставкой из кэша.: Cache the content, but validate the content every time before delivering it from the cache. Эквивалент .Equivalent to .
      • . Никогда не кэширует содержимое.: Never cache the content. Удалите контент, если он был ранее сохранен.Remove content if it has been previously stored.

Expires:Expires:

  • Устаревший заголовок, представленный в HTTP 1.0. Поддерживается для обеспечения обратной совместимости.Legacy header introduced in HTTP 1.0; supported for backwards compatibility.
  • Использует дату окончания срока действия со вторым уровнем точности.Uses a date-based expiration time with second precision.
  • Аналогично .Similar to .
  • Используется, если нет.Used when doesn’t exist.

ВключаютPragma:

  • По умолчанию не учитывается Azure CDN.Not honored by Azure CDN, by default.
  • Устаревший заголовок, представленный в HTTP 1.0. Поддерживается для обеспечения обратной совместимости.Legacy header introduced in HTTP 1.0; supported for backwards compatibility.
  • Используется в качестве заголовка запроса клиента со следующей директивой: .Used as a client request header with the following directive: . Эта директива предписывает серверу предоставить новую версию ресурса.This directive instructs the server to deliver a fresh version of the resource.
  • равно . is equivalent to .

ДИНАМИЧЕСКИЙ КОНТЕНТ И КОНТЕНТ, УПРАВЛЯЕМЫЙ СОБЫТИЯМИ

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

Вот несколько примеров событийного контента:

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

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

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

Валидация кеша

Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок «Cache-control: must-revalidate». Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.

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

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

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

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

Изменяющиеся ответы

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

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

Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка  кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).

Vary: User-Agent

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

Общие принципы сохранения страниц в кэш.

PHP-программа может управлять кэшированием результатов ее работы формируя дополнительные поля в заголовке HTTP ответа вызовом функции Header().

Несколько общих утверждений характерных не только для PHP-программ:

  • Страницы передаваемые по POST никогда не сохраняются в кэш.
  • Страницы запрашиваемые по GET и содержащие параметры (в URL присутствует ‘?’) не сохраняются в кэш, если не указано обратное.

Таким образом в большинстве ситуаций дополнительных инструкций в программу добавлять не надо

Основные моменты на которые следует обратить внимание можно свести к двум:

  • запрет кэширования документов, кэшируемых по умолчанию
  • кэширование документов, не подлежащих кэшированию по умолчанию.

3 способ

Это примерно то же самое что и 2 способ, но гораздо проще и более надёжно. И главное быстрее. Необходимо использовать сторонние CDN сервера с этими библиотеками.

На практике это будет выглядеть вот так:

//Заменяем в коде вызова Я.Метрики этот запрос:
https://mc.yandex.ru/metrika/tag.js
//на такой (например):
https://cdn.jsdelivr.net/npm/yandex-metrica-watch/tag.js

Конкретный CDN сервер можете подобрать по своим предпочтениям. С таким подходом нужды обновлять эти файлики локально не будет. А доступность CDN серверов всё же выше чем нашего домашнего сервачка.

На этом способе я остановился, и он неплохо работает.

Другая технология кэширования в ASP.NET CoreOther caching technology in ASP.NET Core

Кэширование в памятиIn-memory caching

В процессе кэширования в памяти используется память сервера для хранения кэшированных данных.In-memory caching uses server memory to store cached data. Этот тип кэширования подходит для одного сервера или нескольких серверов, использующих закрепленные сеансы .This type of caching is suitable for a single server or multiple servers using sticky sessions . Прикрепленные сеансы означает, что запросы от клиента всегда направляются на один и тот же сервер для обработки.Sticky sessions means that the requests from a client are always routed to the same server for processing.

Для получения дополнительной информации см. Кэширование в памяти в ASP.NET Core.For more information, see Кэширование в памяти в ASP.NET Core.

Распределенный кэшDistributed Cache

Используйте распределенный кэш для хранения данных в памяти, когда приложение размещается в облаке или ферме серверов.Use a distributed cache to store data in memory when the app is hosted in a cloud or server farm. Кэш является общим для серверов, обрабатывающих запросы.The cache is shared across the servers that process requests. Клиент может отправить запрос, который обрабатывается любым сервером в группе, если доступны кэшированные данные для клиента.A client can submit a request that’s handled by any server in the group if cached data for the client is available. ASP.NET Core работает с распределенными кэшами SQL Server, Redisи NCache .ASP.NET Core works with SQL Server, Redis, and NCache distributed caches.

Для получения дополнительной информации см. Распределенное кэширование в ASP.NET Core.For more information, see Распределенное кэширование в ASP.NET Core.

Вспомогательная функция тега кэшаCache Tag Helper

Кэширование содержимого из представления MVC или Razor страницы с вспомогательной функцией тега кэша.Cache the content from an MVC view or Razor Page with the Cache Tag Helper. Вспомогательная функция тега кэша использует кэширование в памяти для хранения данных.The Cache Tag Helper uses in-memory caching to store data.

Для получения дополнительной информации см. Вспомогательная функция тегов кэша в MVC-моделях ASP.NET Core.For more information, see Вспомогательная функция тегов кэша в MVC-моделях ASP.NET Core.

Вспомогательная функция тега распределенного кэшаDistributed Cache Tag Helper

Кэширование содержимого из представления MVC или Razor страницы в сценариях распределенного облака или веб-фермы с помощью вспомогательной функции тега распределенного кэша.Cache the content from an MVC view or Razor Page in distributed cloud or web farm scenarios with the Distributed Cache Tag Helper. Вспомогательная функция тега распределенного кэша использует SQL Server, Redisили NCache для хранения данных.The Distributed Cache Tag Helper uses SQL Server, Redis, or NCache to store data.

Для получения дополнительной информации см. Вспомогательная функция тега распределенного кэша в ASP.NET Core.For more information, see Вспомогательная функция тега распределенного кэша в ASP.NET Core.

Syntaxe

Pour être valables, les directives de mise en cache doivent respecter les règles suivante :

  • Il est recommandé de ne pas faire de distinction entre les majuscules et les minuscules..
  • Les directives multiples sont séparées par des virgules.
  • Certaines directives ont un argument optionnel, qui peut être soit un jeton, soit une chaîne de caractères entre guillemets. (Voir les spécifications pour les définitions)

Les règles standard suivantes peuvent être utilisées par un client HTTP dans une requête :

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

Les règles standard suivantes peuvent être utilisées par un serveur HTTP dans une réponse :

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>

Les directives Extension ne font pas partie du document sur les normes de base de la mise en cache HTTP. Vérifiez leur prise en charge dans la ; les agents-utilisateurs qui ne les reconnaissent pas doivent les ignorer.

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

Как правильно настроить .htaccess

Тут уже каждый решает сам и всё зависит конкретно от вашего сайта. у меня например есть такие правила:

<FilesMatch ".(woff|flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">
Header set Cache-Control "max-age=25920000"
</FilesMatch>
ServerSignature Off
# Fonts
# Add correct content-type for fonts
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
AddType application/x-font-woff .woff2
AddType image/svg+xml .svg
# Compress compressible fonts
# only uncomment if you dont have compression turned on already. Otherwise it will cause all other filestypes n
ot to get compressed
# AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-opentype image/svg+xml
ExpiresActive on
# Add a far future Expires header for fonts
ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
ExpiresByType application/x-font-ttf "access plus 1 year"
ExpiresByType application/x-font-opentype "access plus 1 year"
ExpiresByType application/x-font-woff "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"

Видно, что я не сильно заморачивался и просто кеширую всю статику по максимуму

Особое внимание лишь уделил шрифтам.  После такого отчёт в  PageSpeed Insights будет выглядеть примерно так

И тут нас ждёт самое интересное. Вся статика закеширована, но всё равно ошибки. Ошибки и ругань на скрипты которые грузятся вообще не с нашего сервера. Это скрипты аналитики Яндекс метрики и Google Analitics. Вот такие дела Гугл с Яндексом ругаются на свои же собственные скрипты. Закешировать их мы никак не можем.

Cache-Control directives

The following is a list of the common directives used and configured when using the header. See for a further explanation of the directives available.

uses the header to tell caches that this resource cannot be reused without first checking if the resource has changed on the origin server. This means that will make a trip back to the server to ensure the response has not changed and therefore is not required to download the resource if that is the case.

is similar to in that the response cannot be cached and re-used, however there is one important difference. requires the resource to be requested and downloaded from the origin server each time. This is an important feature when dealing with private information.

A response containing the directive signifies that it is allowed to be cached by any intermediate cache. This however is usually not included in responses as other directives already signify if the response can be cached (e.g ).

The directive signifies that the response can only be cached by the browser that is accessing the file. This disallows any intermediate caches to store the response.

This directive tells the browser or intermediary cache how long the response can be used from the time it was requested. A of means that the response can be used for the next 60 minutes before it needs to fetch a new response from the origin server.

is similar to the above mentioned however the «s» stands for shared and is relevant only to CDNs or other intermediary caches. This directive overrides the and header.

Intermediate proxies sometimes change the format of your images and files in order to improve performance. The directive tells the intermediate proxies not to alter the format or your resources.

Each of these directives serves its own purpose and can be used in a variety of scenarios. To help further simplify things, Ilya Grigorik, a developer at Google, created the decision tree below to help determine what directives should be set for a particular resource.

Кэширование документов, не подлежащих кэшированию по умолчанию

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

header("Cache-control: public");

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

header("Cache-control: private");

Обзор

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

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

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

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

ЗАКЛЮЧЕНИЕ

Кэширование больше не только для статических или событийно-ориентированных сайтов. Выше вы видели множество вариантов кеширования высокодинамичных сайтов WordPress. Хотя изначально требуется некоторая настройка и доработка, конечный результат стоит затраченных усилий. Кэширование динамического контента помогает вам улучшить время до первого байта вашего сайта (TTFB), снизить расходы на хостинг, улучшить SEO и повысить коэффициент конверсии.

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

И если вы хотите пойти дальше, WP Rocket готов к работе с большинством решений кэширования на уровне сервера, обсуждаемых в этой статье. Пришло время зарядить ваш сайт WP Rocket!

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий