Cache control как включить

Обновлено: 03.07.2024

Header type Request header, Response header
Forbidden header name no
CORS-safelisted response header yes

Examples

Preventing caching

The following response header can be sent to disable caching of a resource:

Note: The no-store directive prevents a new resource being cached, but it does not prevent the cache from responding with a non-stale resource that was cached as the result of an earlier request. Setting max-age=0 forces the cache to revalidate (clears the cache).

Cache-Control: no-store, max-age=0

On the opposite, this is a bad way to achieve this:

Caching static assets

For the files in the application that do not change, you can usually add aggressive caching by sending the response header below. This includes static files that are served by the application such as images, CSS files and JavaScript files. In addition, see also the Expires header.

Requiring revalidation

Note: The following header may serve a stale resource, if server is down or loses connectivity.

Заголовок Cache-control позволяет установить правила кеширования страниц сайта в браузере. Это позволит значительно снизить трафик, т.к. клиент не будет постоянно запрашивать одни и те же файлы. Лучше всего кешировать файлы, которые не изменяются (либо изменяются не часто, например раз в день).

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

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

header("Expires: " . gmdate("D, d M Y H:i:s", time() + 60*60*24) . " GMT");

Запрет кеширования

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

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");

header("Cache-Control: no-cache, must-revalidate");

Инструменты

Для проверки и тестирования клиентского кеширования используйте Cache control checker.

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

Nginx умеет кэшировать запросы самостоятельно. Преимущества использования Nginx cache в его простоте по сравнению с Varnish.

Что кешировать?

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

Nginx cache

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

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

Устанавливаем размер кеша в 1G, сохранять его будем в папку

Не забываем создать папку для кеша.

Настройка хостов

Чтобы кеширование заработало, мы должны создать новый хост, который будет слушать 80 порт. А основной хост перенести на какой-то другой порт (например, 81). Кеширующий хост будет посылать запросы на основной либо отдавать данные из кеша.

Каждая страница будет сохраняться в кеш на 1 час

Обычный конфиг только на 81 порту

Cookies и персонализация

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

Имеет смысл также включить кеширование ошибочных запросов на какое-то короткое время. Это позволит избежать частых повторных попыток обратиться к неработающей части сайта.

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

Установим максимальный размер кеша в 1G

Не забываем создать папку

В конфигурации основного хоста, добавляем правила кеширования:

В данном случае мы будем кешировать ответы с кодом 200 на 60 минут

Самое важное

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

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

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

Как перезапустить nginx после обновления конфигурации

Включение и использование log-файлов для проверки работы Nginx

Уменьшение размера картинок при сохранении качества

Как и зачем используется заголовок Cache-control

301 redirect в Nginx'e

Что такое Etag и как его настроить в Nginx

Причины и методы исправления ошибки Gateway Timeout, Nginx

Как настроить Nginx на максимальную эффективность

Где находится nginx.conf и пример настроек

Как использовать try_files в настройках Nginx'a

Основы оптимизации работы Web сервера

Работа приложения с несколькими бэкендами при помощи Nginx

Архитектурные принципы высоконагруженных приложений

Как пофиксить ошибку "110: connection timed out" while reading response header from upstream

Причины возникновения ошибки Ошибка 502 bad gateway в Nginx и методы исправления

Как решить ошибку upstream sent too big header while reading response header from upstream в Nginx

Как улучшить время получения первого байта и отзывчивость веб-сервера


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

Основные принципы использования заголовка Cache-Control

Заголовок Cache-Control определяет количество времени, которое файл должен находиться в кэше, и метод кэширования:

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


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

Что такое max-age?

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

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

Применение max-age

Часть заголовка max-age выглядит следующим образом:

Значение max-age задается в секундах.

Часто используемые значения для max-age :

  • Одна минута: max-age=60 ;
  • Один час: max-age=3600 ;
  • Один день: max-age=86400 ;
  • Одна неделя: max-age=604800 ;
  • Один месяц: max-age=2628000 ;
  • Один год: max-age=31536000 .

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

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

Часть директивы кэширования в браузере htaccess приведенного выше заголовка выглядит следующим образом:

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

Мы рассмотрим три основные директивы Cache-Control :

public

Официальная спецификация определяет ее следующим образом:


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

private

Директива private означает, что ресурс предназначается только для конкретного пользователя. В качестве примера можно привести страницу Twitter . Когда вы заходите в Twitter , вы видите одно, а другой человек, открывающий тот же URL-адрес , видит другое содержимое. Даже если информация на этой странице общедоступна, она « специфична » для конкретного человека.

Официальная спецификация определяет ее следующим образом:

no-store

Директива no-store является самым категоричным запретом на кэширование. Официальная спецификация определяет ее следующим образом:


Еще раз отмечу, что само по себе это ничего не гарантирует.

Типы файлов

Два вопроса, которые должен задать себе веб-мастер:

  • Какие типы файлов нужно хранить с помощью кэширования файлов htaccess?
  • Как долго их нужно хранить в кэше?

Какие типы файлов должны храниться в кэше?

Я хотел бы отметить следующие типы файлов:

Что следует учесть

Только вы можете определить, какие инструкции больше всего подходят для вашего сайта. Если вы собираетесь изменить какой-либо ресурс ( например, файл CSS ), и этот ресурс кэшируется в браузере htaccess , то стоит подумать над тем, чтобы изменить имя файла. Тогда обновленный файл CSS будет просмотрен всеми пользователями. Это называется URL-дактилоскопией .

Как добавить Cache-Control на сайт

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

Файл .htaccess

Большинство использует для добавления заголовков файл .htaccess .

Пример кода файла .htaccess

Общий код для установки заголовка Cache-Control с помощью файла .htaccess :

Но приведенный выше код не позволяет задавать различные инструкции кэширования сайта htaccess для различных типов файлов.

Чтобы применить разные заголовки Cache-Control к различным типам файлов, мы будем использовать:

Приведенный выше код означает следующее:

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

Мы можем добавить в файл .htaccess следующий код:

Приведенный выше код состоит из двух блоков: один для изображений и один для CSS и JS-файлов . У нас может быть несколько блоков в файле .htaccess .

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

Используйте сочетание filesMatch и Header , чтобы создать отдельные инструкции для конкретных типов файлов ( примеры кода для файла .htaccess подходят ).

NGINX

Используя директивы expires, можно добавить инструкции кэширования в блоки сервера или местоположения:

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

Litespeed

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

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

Syntax

Caching directives follow the validation rules below:

  • Case-insensitive, but lowercase is recommended.
  • Multiple directives are comma-separated.
  • Some directives have an optional argument, which can be either a token or a quoted-string. (See spec for definitions)

Cache request directives

Cache response directives

Extension Cache-Control directives

Directives

Cacheability

Directives that define:

  • if a response/request can be cached (where it may be cached) and
  • if a response/request should be validated with the origin server before caching.

The response may be stored by any cache, even if the response is normally non-cacheable.

The response may be stored only by a browser's cache, even if the response is normally non-cacheable. If you mean to not store the response in any cache, use no-store instead. This directive is not effective in preventing caches from storing your response.

The response may be stored by any cache, even if the response is normally non-cacheable. However, the stored response MUST always go through validation with the origin server first before using it, therefore, you cannot use no-cache in-conjunction with immutable . If you mean to not store the response in any cache, use no-store instead. This directive is not effective in preventing caches from storing your response.

The response may not be stored in any cache. Note that this does not prevent a valid pre-existing cached response being returned. Clients can set max-age=0 to also clear existing cache responses, as this forces the cache to revalidate with the server (no other directives have an effect when used with no-store ).

Expiration

The maximum amount of time a resource is considered fresh. Unlike Expires , this directive is relative to the time of the request.

Overrides max-age or the Expires header, but only for shared caches (e.g., proxies). Ignored by private caches.

Indicates the client will accept a stale response. An optional value in seconds indicates the upper limit of staleness the client will accept.

Indicates the client wants a response that will still be fresh for at least the specified number of seconds.

Indicates the client can accept a stale response, while asynchronously checking in the background for a fresh one. The seconds value indicates how long the client can accept a stale response. Note that the time does not start at the time of the request itself, but, for example, after max-age has elapsed. See "Keeping things fresh with stale-while-revalidate " for more information.

Indicates the client can accept a stale response if the check for a fresh one fails. The seconds value indicates how long the client can accept the stale response after the initial expiration.

Revalidation and reloading

Indicates that once a resource becomes stale, caches do not use their stale copy without successful validation on the origin server.

Like must-revalidate , but only for shared caches (e.g., proxies). Ignored by private caches.

Other

An intermediate cache or proxy cannot edit the response body, Content-Encoding , Content-Range , or Content-Type . It therefore forbids a proxy or browser feature, such as Google’s Web Light, from converting images to minimize data for a cache store or slow connection.

Set by the client to indicate "do not use the network" for the response. The cache should either respond using a stored response, or respond with a 504 status code. Conditional headers such as If-None-Match should not be set. There is no effect if only-if-cached is set by a server as part of a response.

Читайте также: