Prevent unnecessary network requests with the http cache

Кэширование объектов в WordPress

Объектное кэширование (object cache) реализовано в самом ядре WordPress. Этот механизм позволяет хранить объекты произвольного типа в памяти и полезен в основном разработчикам тем и плагинов для WordPress.

Например, при запросе опции из базы данных MySQL с помощью функции , WordPress сохранит результат этой функции в памяти, и при последующем подобном обращении выдаст результат из памяти, не делая при этом запросов в базу данных.

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

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

Постоянное кэширование объектов

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

На первый взгляд это совершенно не выгодно, но если посчитать сколько раз WordPress вызывает функцию для обработки одного запроса (около 500 раз), то выгода от кэширования объектов становится очевидной.

Тем не менее, постоянное кэширование объектов (или внешнее кэшированое) в WordPress легко реализуется с помощью сторонних плагинов, например Memcached Object Cache или APC Object Cache. Оба плагина позволяют использовать оперативную память сервера для хранения объектов WordPress, при этом объекты не пропадают при окончании запроса. Такой подход существенно снижает нагрузку на базу данных MySQL.

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

Кэшируем весь сайт

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

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

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

Узнали на чем работает сайт (apache, nginx и тому подобное).
Научились закачивать .htaccess на компьютер.
Отредактировали файл доступов.
Смогли закинуть обратно на сервер.
Поставили плагин nix gravatar cache.

P.S. Если что-то не получилось то смело пишите комментарии, отвечу и помогу.

Как работает кэширование?

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

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

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

Есть несколько вещей, на которые стоит обратить внимание, прежде чем вы добавите их для всего сайта

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

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

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

Cache-control

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

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

Обычно этого заголовка достаточно для того, чтобы все заработало:

закэширует результат запроса в браузере на 60 секунд

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

Expires

Дополнительный заголовок HTTP Expires указывает дату и время, когда браузер должен обновить кэш:

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

Этот заголовок следует использовать вместе с Cache-Control.

Vary

Заголовок Vary позволяет установить дополнительные правила для кэширования запросов:

Браузер будет знать, что контент может отличаться в зависимости от версии сайта (например, мобильной и настольной)

Introduction

As of Apache HTTP server version 2.2
and are no longer marked
experimental and are considered suitable for production use. These
caching architectures provide a powerful means to accelerate HTTP
handling, both as an origin webserver and as a proxy.

and its provider modules
and
provide intelligent, HTTP-aware caching. The content itself is stored
in the cache, and mod_cache aims to honour all of the various HTTP
headers and options that control the cachability of content. It can
handle both local and proxied content.
is aimed at both simple and complex caching configurations, where
you are dealing with proxied content, dynamic local content or
have a need to speed up access to local files which change with
time.

on the other hand presents a more
basic, but sometimes useful, form of caching. Rather than maintain
the complexity of actively ensuring the cachability of URLs,
offers file-handle and memory-mapping
tricks to keep a cache of files as they were when Apache was last
started. As such, is aimed at improving
the access time to local static files which do not change very
often.

As presents a relatively simple
caching implementation, apart from the specific sections on and , the explanations
in this guide cover the caching
architecture.

Сжать фотографии, иллюстрации и другую графику

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

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

Как оптимизировать картинки для сайта:

Подберите разрешение.
Незачем загружать изображение в большом разрешении, если оно будет отображаться в маленьком без увеличения по клику.
Подберите формат.
JPEG подходит для фотографий, PNG для дизайнерской графики, SVG для вектора. Google также индексирует формат WebP, который весит меньше, но не все браузеры его поддерживают. Яндекс не индексирует SVG и изображения в скриптах.
Уменьшайте количество цветов.
Изображения, где нет сложных градиентов, требуют меньшего количества цветов. Можно оптимизировать картинку без потери качества, выбрав палитру меньше, тогда изображение будет хранить меньшее количество битов на пиксель.Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета)

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

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

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

Минифицируйте.
Удаляйте XML-разметку с лишними метаданными, она появляется при работе с картинками в некоторых графических приложениях. EXIF — информацию о геоданных, дате съемки, фотокамере тоже можно удалить.

Используйте алгоритмы сжатия.
Настройте на сервере gzip-сжатие для SVG-графики.

Инструменты и сервисы для оптимизации изображений на сайте:

CompressJPEGСервис для сжатия JPEG и PNG без потерь качества.
PunyPNG
Инструмент сжимает PNG, JPEG и GIF.
TinyPNGИнструмент для оптимизации изображений в PNG и JPEG.
JpegtranИнструмент для оптимизации JPEG-изображений.
OptipngИнструмент для оптимизации PNG без потерь.
PngquantИнструмент сжимает PNG-изображения.

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

Кэш на уровне приложения

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

Мемоизация

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

Эту функцию можно вызывать из любого места кода. Однако использование такой техники вызывает определённые проблемы

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

Интеллектуальное кэширование в памяти

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

Многие библиотеки предоставляют этот шаблон, но память приложения — не бесконечный ресурс. Например, менеджер кэша для Node не управляет объёмом потребляемой памяти. Также это может стать проблемой, если ваше приложение кэширует данные в больших объёмах, потребляя всю доступную память.

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

Совместное кэширование

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

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

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

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

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

Configure Cache-Contol Headers for Apache and Nginx Webserver

In this section, we will show you how to set the HTTP Cache-Control header in Apache and Nginx.

Apache

For the Apache web server, you will need edit your website virtual host configuration file in order to implement the HTTP Cache-Control header, for example:

nano /etc/apache2/sites-enabled/webdock.conf

Add the following contents:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
    Header set Cache-Control "max-age=3600, public"
</filesMatch>

If you want to enable Cache-Control for all files, add Header set line outside the filesMatch block.

As you can see, we set the Cache-Control header’s max-age to 3600 seconds and to public for the listed files.

This can also be set in a .htaccess file in any directory below your web root. If you are using SSL you should consider adding this to the ssl version of your virtual host configuration, which is also placed in /etc/apache2/sites-enabled/

Nginx

For the Nginx web server, you will need to edit your website virtual host configuration file to implement the HTTP Cache-Control header, for example:

nano /etc/nginx/sites-enabled/webdock

Add the following contents:

location ~* \.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$ {
    expires 1h;
    add_header Cache-Control "public, no-transform";
}

If you want to enable Cache-Control for all files, add a add_header line without the enclosing location block, as what the location block does is specify specific filetypes you are targeting with your directives (ico,pdf,flv etc.).

Использовать настройки источника

CDN-серверы при запросе контента с сервера-источника ориентируются на заголовок «Cache-Control», настроенный на источнике, и кешируют контент на время, заданное в качестве его значения.

Если на сервере-источнике отсутствует заголовок Cache-Control, то CDN использует время хранения, заданное в опции «Время жизни кеша по умолчанию».

Эта настройка применяется только для кодов ответов 200, 201, 204, 206, 301, 302, 303, 304, 307, 308, остальные коды не кешируются.

Обратите внимание! Независимо от настроек опции контент удаляется из кеша CDN-серверов через 36 часов, если он не запрашивается конечными пользователями

Настройка кеширования на источнике

По умолчанию мы наследуем все заголовки, заданные на источнике. Время хранения кеша на CDN-серверах определяется HTTP-заголовком Cache-Control.

Добавьте заголовок Cache-Control на ваш сервер в файл .htacess или nginx.conf. Заголовок должен содержать директивы public, max-age.

Пример конфигурации Apache

<ifModule mod_headers.c>  <FilesMatch "\.(gif|ico)$">      Header set Cache-Control "max-age=31536000, public"  </FilesMatch>   <FilesMatch "\.(js)$">      Header set Cache-Control "max-age=31536000,               public"  </FilesMatch>  </ifModule>

Пример конфигурации Nginx

server {    #...    location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {      add_header Cache-Control "max-age=88000,  public";    }    #... }

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

Использование в приложении

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

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

Включим кэш на 1 час

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

Использование на Web сервере

Заголовки для картинок и статических файлов (JS/CSS) нужно устанавливать на Web сервере.

Nginx

В Nginx кэширование включается инструкцией expires:

server {
...
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
expires max;
}
...
}

Включит кэш на бесконечный срок для файлов с перечисленными расширениями

Apache

В Apache кэширование включается модулем mod_expires и выглядит так:

<FilesMatch ".(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$">

Header set Cache-Control "max-age=2592000, must-revalidate"

Включает кэш для файлов на 1 месяц

Задать настройки на CDN

CDN-серверы запрашивают контент с источника и кешируют его на время, заданное в опции «Задать настройки на CDN».

Настройка имеет два параметра:

«Время жизни кеша»
«Расширенные правила кеширования»

Используйте параметр «Время жизни кеша», чтобы задать время хранения кеша для запросов с кодами ответа 200, 206, 301, 302. 4xx и 5xx коды ответа кешироваться не будут.

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

Значения параметра «Расширенные правила кеширования» имеют больший приоритет, чем значения параметра «Время жизни кеша».

Например,

В настройках опции вы выбрали «Задать настройки на CDN» и указали «Время жизни кеша» равное 4 дням.

В расширенных правилах добавили 3 правила:

Код ответа 200 – 10 минут
Код ответа 404 — 1 минуту

В результате настроек запросы будут кешироваться так:

Запросы с кодом ответа 200 – 10 минут
Запросы с кодом ответа 404 — 1 минуту
Запросы с кодом ответа 206, 301, 302 — 4 дня
4хх (кроме 404), 5хх — кешироваться не будут

Настройка кэширования для proxy_pass

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

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

Открываем конфигурационный файл nginx:

vi /etc/nginx/nginx.conf

В секцию http добавляем:

http {
…
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:64m inactive=2h max_size=2g;
…
}

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

/var/cache/nginx — путь хранения кэша.
levels — уровень вложенности каталогов. В данном примере мы задаем настройку, при которой в каталог с кэшем будет создан каталог, а в ней — еще один каталог.
keys_zone — имя зоны в разделяемой памяти, где будет храниться кэш, а также ее размер.
inactive — задает время, после которого кэш будет автоматически чиститься.
max_size — максимальный размер данных под кэш. Когда место заканчивается, nginx сам удаляет устаревшие данные.

Создаем каталог для хранения кэша и задаем владельца:

mkdir /var/cache/nginx

chown nginx:nginx /var/cache/nginx

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

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

vi /etc/nginx/conf.d/default.conf

… и добавим к proxy_pass кэширование — мы получим что-то на подобие:

location / {
if ($http_cookie ~* «.+» ) {
set $cookie_cache_bypass 1;
}
proxy_cache_bypass $cookie_cache_bypass;
proxy_pass http://localhost:3000;
…
proxy_cache all;
proxy_cache_valid 404 502 503 5m;
proxy_cache_valid any 1h;
proxy_cache_use_stale error timeout invalid_header updating;
}

* где:

set $cookie_cache_bypass 1 — задаем значения переменной $cookie_cache_bypass, если передаются куки. Необходимо для предотвращения отдачи устаревших данных.
proxy_cache_bypass — не отдавать данные из кэша. В нашем случае, применяется при куках.
proxy_pass — передает запросы на бэкэнд.
proxy_cache — включаем кэширование.
proxy_cache_valid — задает время кеширования. В нашем примере первый параметр задает кэширование страниц с кодами ответов 404, 502, 503 на 5 минут, второй — для всего остального на 1 час.
proxy_cache_use_stale — указывает, в каких случаях можно отдать устаревший кэш.

Применение настроек

NGINX настроен. Проверим корректность настроек:

nginx -t

Если ошибок нет, применяем их:

systemctl restart nginx

Теперь заходим на сайт и смотрим в каталог с кэшем — в нем должны появиться каталоги и файлы:

ls /var/cache/nginx/

Мы должны увидеть что-то на подобие:

drwx——. 3 nginx nginx 4096 Jan 25 16:09 0
drwx——. 5 nginx nginx 4096 Jan 25 16:09 2
drwx——. 5 nginx nginx 4096 Jan 25 16:15 3
drwx——. 3 nginx nginx 4096 Jan 25 16:09 4
drwx——. 4 nginx nginx 4096 Jan 26 05:08 5
drwx——. 3 nginx nginx 4096 Jan 25 16:09 6
drwx——. 3 nginx nginx 4096 Jan 26 04:18 7
drwx——. 3 nginx nginx 4096 Jan 25 16:10 8
drwx——. 5 nginx nginx 4096 Jan 25 16:15 a
drwx——. 3 nginx nginx 4096 Jan 25 16:09 b
drwx——. 5 nginx nginx 4096 Jan 26 04:19 e
drwx——. 3 nginx nginx 4096 Jan 25 19:55 f

What Is Cache-Control, Then?

Cache-control is one of the main methods to control this browser caching behavior, with the other being expires headers.

Basically, cache-control lets you set these “expiration” dates to control whether a visitor’s browser will load a resource from its local cache or send a request to your site’s web server to download the resource.

It gives you lots of control over how each individual resource behaves and it also lets you control who can cache your content. For example, you can say that a visitor’s browser can cache a certain image, but a CDN (such as Cloudflare) cannot cache it.

More specifically, cache-control is an HTTP header, which brings us to another term that we need to define.

What Are HTTP Headers?

HTTP, short for Hypertext Transfer Protocol, governs how clients and servers communicate. For our purposes, a client is a visitor’s web browser and a server is your WordPress site’s server.

When a client needs a file, it sends a request to the server and the server sends a response to the client.

For example, if your website has an image, a visitor’s browser would first request that image from the server and then the server would respond with the image file. The browser would then repeat the same process for every resource on your site, including CSS stylesheets, JavaScript, etc.

HTTP headers let clients or servers send additional information with those client requests and server responses. There are different types of HTTP headers, with cache-control being one of them.

Most modern web browsers include developer tools that let you see the HTTP headers associated with every request/response involved in loading a web page.

In Chrome, you can:

Open developer tools (CTRL + Shift + I)
Go to the Network tab
Reload the page
Select the resource that you want to analyze
Look at the Headers tab

For example, here are all of the HTTP response headers for loading the featured image for one of WP Rocket’s blog posts:

HTTP response headers in WP Rocket website

You can see that cache-control is one of those headers, but there are lots of other headers that communicate additional information. We even added a nice little easter egg in the x-curious header.

HTTP headers can go in both directions. That is, your web browser can attach HTTP headers to the request that it makes to the server, and the server can attach HTTP headers to the response that it sends to the browser.

HTTP headers consist of key-value pairs. The “key” is the part to the left of the colon, while the “value” is the part to the right. More specifically, the value is called the directive for cache-control.

In the example above, the key is “cache-control” and the value/directive is “max-age=31536000” (more on what this means next).

Какие еще есть способы активировать кэширование через файл htaccess

Помимо директивы Cache Control есть и другие опции, которые позволят вам включить кэширование для браузеров посетителей. Но при этом на вашем сервере должен быть активирован модуль mod _ expires. Этот модуль по аналогии с директивой Cache Control будет отправлять кэшируемые файлы вместе с HTTP-заголовками в браузеры пользователей. Директивы этого модуля стоит заключать между тегами в файле htaccess.

В первую очередь, вам следует активировать модуль отправки кеша через заголовки при помощи строки ExpiresActive On. Уже после этого в другой строке при помощи специальной команды вы сможете указать период, который кэш будет храниться на устройствах посетителей. Сделать это можно при помощи директивы ExpiresDefault. В этой директиве можно указывать промежуток как в секундах, так и в других временных единицах. Вот как будет выглядеть указание периода кэширования в 1 день при помощи записи в секундах: ExpiresDefault A 86400. А это аналогичная запись, только в другом формате: ExpiresDefault » access plus 1 days «.

Чтобы указать для различных типов файлов разные периоды кэша, вам следует использовать опцию ExpiresByType. После нее нужно будет прописать тип файла, а также их формат и период кэширования. Вот как выглядит активация кэша картинок с расширением gif на период в 2 месяца: ExpiresByType image/gif «access plus 2 months». Для текстовых файлов вместо image указывайте text, как и для скриптов и css-файлов. Для xml, html и прочих подобных расширений пишите application. Настройте таким образом кэширование для всех необходимых типов файлов.

Static Files Caching

Static files are automatically cached at the edge after the first request. Note that no manual adjustments are necessary to make this work.

Static files are cached for up to 31 days. However, when you redeploy the cache is effectively invalidated so we always serve the latest version. If a file is unchanged it can persist across deployments, as static files are cached by their hash.

By default we return a header containing to prevent clients (e.g. browsers) from caching the file locally. This gives you the most flexibility as users get the latest file from our Global CDN immediately after deploying. This can be overridden with the property in your file.