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

Содержание

Введение

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


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

Инвалидация кеша

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

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

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

Создаем слушатель этих событий:

Этот код будет удалять закешированные значения после каждого обновления или удаления сущностей Post. Инвалидация списков сущностей, таких как top-5 статей или последних новостей, будет чуток посложнее. Я видел три стратегии:

Стратегия «Не инвалидируем»

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

Но некоторым проектам действительно важно иметь свежие данные в этих списках

Стратегия «Найти и обезвредить»

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

Выглядит уродливо, зато работает.

Стратегия «хранить id»

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

Examples

For more information about Cache-Control directives at origin servers, refer to the Mozilla Cache-Control documentation.

Cache a static asset Cache-Control: public, max-age=86400

Make sure a secret asset is never cached Cache-Control: no-store

Cache asset on browsers, but not on proxy caches Cache-Control: private, max-age=3600

Cache an asset in client and proxy caches, but prefer revalidation when served Cache-Control: public, no-cache

Cache an asset in proxy caches, but REQUIRE revalidation by the proxy when served Cache-Control: public, no-cache, proxy-revalidate or Cache-Control: public, s-maxage=0

Cache an asset in proxy caches, but REQUIRE revalidation by any cache when served Cache-Control: public, no-cache, must-revalidate

Кэширование в WordPress

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

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

Hostinger, например, предлагает специальный хостинг для WordPress с уже встроенными функциями кэширования. Самый дешевый тарифный план WordPress хостинга стоит примерно 1.70$ в месяц. Более того, Hostinger предлагает 30-дневную гарантию возврата денег, если вас не удовлетворят услугами.

Кроме того, существуют отличные плагины WordPress для управления кешированием.

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

1. W3 Total Cache

W3 Total Cache — один из самых популярных бесплатных плагинов кеширования WordPress. Дополнение идеально подходит для тех, кто хочет попробовать разные типы кэширования, поскольку предлагает их все — от кеширования страниц до фрагментарного.

2. WP Super Cache

WP Super Cache предлагает уникальный способ кеширования сайтов. Плагин включает три модели кэширования — экспертное (expert), простое (simple) и WP-кэш (WP-cache). Простая модель использует PHP для обслуживания статических файлов. Экспертное кеширование использует Apache mod_rewrite, а модель WP-кэш задействует страницы предыдущих пользователей.

3. Autoptimize

Autoptimize — плагин кеширование WordPress, в котором основное внимание уделяется скриптам и стилям. Он простой и понятный

Всё, что от вас требуется — это просто отметить предлагаемые опции для оптимизации HTML, Javascript и CSS сайта.

Кеширование отношений

Кеширование сущностей с отношениями требует повышенного внимания.


Этот код выполняет два запроса. Получение сущности по и комментариев по . Реализуем кеширование:

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

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

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

Сравнение плагинов

Методика

Все тесты проводились на одинаковой HTML странице, содержащей CSS, JS и несколько медиа объектов, чтобы охватить наиболее общий спектр типов. Проверки функциональности делались по каждому критерию из приведенных выше и сводились в таблицу. Каждому критерию заданы веса важности влияния на общую оценку (они видны в приложенной детальной таблице). Измерение времени загрузки страницы сначала было сделано без оптимизации, дальше происходил замер с при работе каждого плагина и делалось относительное сравнение времен. Таким образом обеспечивается достаточная независимость от скорости хостинга. Окружение взято самое последнее:WordPress 4.9.8, PHP 7.2.10 с включенным кешированием (OpCache), MariaDB(MySQL) 10.3.9, Apache 2.4.35.

  • В разделе отладки по нажатию F12 в разделе Network хорошо видны времена разных стадий загрузки и HTTP заголовки ответов сервера для проверки управления кешом браузера и компрессией. Также видно объединение CSS и JS в один или несколько файлов.
  • Через View Page Source по правой кнопке проводился анализ выданного содержимого на включение CSS, качество минификации (только HTML, JS, CSS) и признаков отложенной загрузки скриптов JS (в описании тега ссылки на скрипт должны присутствовать атрибуты defer или async).
  • Отложенная загрузка JS также проверялась на сохранении работоспособности сайта, т.к. Google Page Speed Test может показать, что все круто, а скрипты не работают.

Результаты

Plugin Role Score
Total Server Cache Client Cache Optimize Manage
Full 96% 98% 71% 100% 100%
Full 93% 95% 71% 97% 75%
Full 90% 98% 100% 83% 75%
Full 88% 98% 71% 83% 100%
Full 84% 55% 100% 100% 100%
Full 82% 98% 100% 67% 75%
Full 79% 50% 71% 100% 100%
Full 76% 50% 71% 95% 100%
Full 70% 50% 71% 83% 100%
Full 64% 98% 0% 53% 75%
Optimize 53% 48% 71% 50% 100%
Full 52% 50% 71% 47% 100%
Server Cache 48% 95% 0% 20% 100%
Optimize 47% 2% 71% 70% 100%
Server Cache 47% 98% 0% 20% 50%
Optimize 44% 2% 36% 73% 100%
Full 44% 50% 71% 30% 100%
Server Cache 43% 95% 0% 10% 100%
Server Cache 43% 95% 0% 10% 100%
Server Cache 43% 95% 0% 10% 100%
Server Cache 43% 95% 0% 10% 100%
Server Cache 43% 95% 0% 10% 100%
Optimize 36% 2% 0% 65% 100%
Client cache 31% 23% 71% 30% 0%
Optimize 27% 0% 0% 52% 50%
Full 27% 25% 0% 30% 100%
Client cache 23% 0% 71% 30% 0%
Server Cache 20% 48% 0% 0% 100%
Full 16% 25% 0% 10% 50%
Client cache 3% 0% 29% 0% 0%

Overview

Cache-Control headers are one way for web administrators to tell Cloudflare how to handle content from the origin. This article explains how Cloudflare makes caching decisions during the request and response phase for a resource, and the options you have for setting Cache-Control directives at your origin server. 

Request phase

In the request phase, the client request URL is matched against a list of cacheable file extensions. If the request matches an extension on this list, Cloudflare serves the resource from cache if present. If the content is stale in the Cloudflare cache, Cloudflare attempts to revalidate the content with the origin before serving the response to the client.

It is possible to modify what Cloudflare deems cacheable via the Cache Level setting in the Cloudflare Page Rule app. 

To learn more about creating Page Rules, refer to our Page Rules tutorial.

As an example, Cache Everything skips the extension check, and all content is treated as cacheable. Refer to Cloudflare’s guide on how to enable Cache Everything.

Response phase

If Cloudflare deems a request cacheable, we first examine our caches in multiple network locations for content. If the resource is not present in cache, Cloudflare requests the resource from your origin web server to fill our cache. The response is then sent to the client who initiated the request.

At this point, our cache logic examines the HTTP response received from your origin server.

Based on how Cloudflare interprets request headers, the response is either deemed cacheable and written to disk (for use with the next request for the same resource) or deemed un-cacheable (resulting in the next request missing cache and repeating this flow).

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

Первые кандидаты на кеширование — это запросы, которые выполняются очень часто, но их план выполнения не самый простой. Лучший пример — top-5 статей на главной странице, или последние новости. Кеширование таких значений способно сильно улучшить производительность главной страницы.

Обычно, выборка сущностей по id, используя работает очень быстро, но если эта таблица сильно загружена многочисленными запросами update, insert и delete, уменьшение количества select запросов даст хорошую передышку базе данных. Сущности с отношениями , которые будут загружаться каждый раз, тоже хорошие кандидаты на кеширование. Когда я работал на проекте с 10+ миллионов посетителей в день мы кешировали почти любой select запрос.

Browser support

As for browser support, the directive isn’t universal just yet. The list below outlines which browsers support and which ones either don’t support it or have their own mechanism in place to imitate the functionality.

  • Firefox — supported since Firefox 49.
  • Microsoft Edge — supported since Edge 15.
  • Chrome — Not supported. as Chrome already has a feature implemented that prevents subresource revalidation on reload.
  • Safari — Supported in Safari Technology Preview 24.

It should also be noted that Firefox only honors the directive over HTTPS. All browsers that do not support the directive simply ignore it, therefore it is safe to add and won’t cause any conflicts.

Http заголовки для управления клиентским кэшированием

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

Без кэша (при отсутствии кэширующих http-заголовков)

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

Заголовок ответа и заголовок запроса .

Идея заключается в том, что сервер добавляет заголовок к файлу (ответу), который он отдает браузеру.

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

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

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

Заголовок ответа и заголовок запроса .


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

Идея заключается в том, что при создании и каждом изменении сервер помечает файл особой меткой, называемой , а также добавляет заголовок к файлу (ответу), который он отдает браузеру:

Теперь браузер знает, что файл актуальной версии имеет равный “686897696a7c876b7e”. В следующий раз, когда брузеру понадобится тот же файл, он отправит запрос с заголовком .

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

Заголовок

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

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

Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.

Заголовок с директивой .

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

Для справки:

  • 1 день = 86400 секунд
  • 1 неделя = 604800 секунд
  • 1 месяц = 2629000 секунд
  • 1 год = 31536000 секунд

К примеру:

У заголовка , кроме , есть и другие директивы. Давайте коротко рассмотрим наиболее популярные:

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

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

no-cache Позволяет указать, что клиент должен делать запрос на сервер каждый раз. Иногда используется с заголовком , описанным выше.

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

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

proxy-revalidate Это то же, что и , но касается только кэширующих прокси серверов.

s-maxage Практически не отличается от , за исключением того, что эта директива учитывается только кэшем резличных прокси, но не самим браузером пользователя. Буква “s-” исходит из слова “shared” (например, CDN). Эта директива предназначена специально для CDN-ов и других посреднических кэшей. Ее указание отменяет значения директивы и заголовка . Впрочем, если вы не строите CDN-сети, то вам вряд ли когда-либо понадобится.

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.

What is Cache-Control: immutable?

The directive was first introduced in Firefox 49 to provide the browser with hints as to which resources never change. Why introduce this directive you might ask? Well, let’s say you have a page that loads static content which likely won’t change for extended periods of time (e.g. images, JavaScript, CSS files, etc). Upon each reload, the browser needs to check the server to see whether those assets need to be revalidated thus slowing down performance.

Of course, these assets will return a HTTPS status instead of a status, as long as they are unchanged, however, the revalidation process still takes time and uses bandwidth.

In fact, for smaller assets, going through the server side validation process can often take just as long as transferring the complete asset itself. Therefore, for certain assets which you are confident do not require conditional revalidation ( or ), it can be beneficial to mark them as .

Шаг 1 — Редактирование файла .htaccess

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

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 7 days"
</IfModule>
## EXPIRES CACHING ##

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

Как это работает?

Когда приложения хочет получить некоторые данные из базы, например сущность Post по его id, оно формирует уникальный ключ кеширования для этого случая ( вполне подходяще) и пытается найти значение по этому ключу в быстром key-value хранилище(memcache, redis, или другое). Если значение там — то приложение использует его. Если нет, забирает его из базы данных и сохраняет в кеш по этому ключу для будущих использований.

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

После истечения этого времени memcache или redis «забудут» про него и приложение возьмет свежее значение из базы.


Пример:

Здесь я кладу сущность Post в кеш на 15 минут (начиная с версии 5.8 laravel использует секунды в этом параметре, раньше там были минуты). Фасад также имеет удобный метод для этого случая. Этот код делает ровно тоже самое, что и предыдущий:

Недостатки и отрицательный эффект от кеширования сайта

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

immutable caching example

The directive is quite simple to implement. Like other directives, it just needs to be defined within the HTTP response header, like for a specific location or file type, within your server configuration file. Since is complemented by the lifetime expiry value expressed by (or a similar directive), here is an example of what your header might look:

In Facebook’s case, you can clearly see this directive added to their subresources by running a simple curl command:

Additionally, by checking the Network tab in Firefox’s developer tools, we can clearly see that although the page is refreshed multiple times, the status remains instead of . Although, if we look under the Transfer tab, we can see that each subresource asset is coming from cache instead of the server.

Additional HTTP Cache Headers

In addition to cache-control, notable HTTP cache headers include:

  • Expires – This header specifies a fixed date/time for the expiration of a cached resource. For example,  signals that the cached resource expires on May 13, 2017 at 7:00 am GMT. The expires header is ignored when a cache-control header containing a max-age directive is present.
  • ETag – A response header that identifies the version of served content according to a token – a string of characters in quotes, e.g.,  – that changes after a resource is modified. If a token is unchanged before a request is made, the browser continues to use its local version.
  • Vary – A header that determines the responses that must match a cached resource for it to be considered valid. For example, the header  specifies that a cached version must exist for each combination of user agent and language.

See how Imperva CDN can help you with website performance.

Request Demo or learn more

Не используйте кеш в операциях записи

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

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

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

Что такое кеширование

Кеширование (caching) — это технология или процесс создания копии данных на быстродоступных носителях информации (кеш, cash). Проще говоря и применяя к реалиям сайтостроения, это может быть создание статической html-копии страницы или её части, которая генерируется с помощью PHP-скриптов (или иных других, как-то Perl, ASP.net), смотря на каком языке написан CMS сайта) и сохраняется на диске, в оперативной памяти или даже частично в браузере (рассмотрим подробнее ниже). Когда произойдёт запрос страницы от клиента (браузера), вместо того, чтобы заново собирать её скриптами, браузер получит её готовую копию, что намного экономнее по затратам ресурсов хостинга, и быстрее, так как передать готовую страницу занимает меньше времени (порой значительно меньше), чем её создание заново.

Interaction with other Cloudflare features

Edge Cache TTL

 Page Rules override s-maxage and disable revalidation directives if present. When origin cache control is enabled at Cloudflare, the original Cache-Control header is passed downstream from our edge even if Edge Cache TTL overrides are present. Otherwise, when origin cache control is disabled at Cloudflare (the default), Cloudflare overrides the origin cache control.

Browser Cache TTL

Browser Cache TTL Page Rules override max-age settings passed downstream from our edge, typically to your visitor’s browsers.

Gzip and Other Compression

Compression is disabled when the no-transform directive is present. If the original asset fetched from the origin is compressed, it is served compressed to the visitor. If the original asset is uncompressed, compression is not applied.

Принципы

основные свойства

  • Server cache (кеш на стороне сервера)
    • Page load time (время загрузки страницы) Один из самых важных параметров. Чем меньше время, тем быстрее клиент получает ответ. Можно конечно выбрать плагин с большим временем, но потом при высоких нагрузках на сервер придется увеличивать производительность железа, а это затраты, которых можно было бы избежать.
    • Caching method (способ хранения) Максимальное сохранение всех подготовленных объектов HTML, JS, CSS, желательно еще и в сжатом состоянии для экономии времени обработки на сервере и увеличения скорости выдачи результата.
  • Client cache (кеш на стороне клиента)
  • Optimize (оптимизация)
    • Inline (включение) Содержимое CSS вставляется в HTML, что в итоге уменьшает число обращений к серверу. CSS лучше включать, т.к. на практике сложно разделить его на нужные и не очень части.
    • Postpone (отложенная загрузка) Отложенная загрузка JS скриптов, не влияющих на начальное отображение страницы. Тоже важнейшая метрика, влияющая на скорость загрузки страницы пользователю. JS лучше отложить, чем включать напрямую в HTML, т.к. их обычно просто разделять и включение повлечет увеличение объема HTML, что может привести к загрузке в несколько итераций, что равноценно появлению дополнительных запросов.
    • Minify (минификация) В содержимом HTML, JS и CSS зачастую есть лишние части, такие как пробелы, переносы строк, комментарии. Все это лучше убирать, чтобы еще больше снизить размер объектов.
    • Compress (сжатие) Сжатие данных алгоритмом GZip (Deflate) для уменьшения объема передаваемых данных. Т.к. HTML, JS и CSS по сути текстовые форматы, то они хорошо сжимаются.
  • Manage (управление)
    • Refresh (обновление) В том случае, когда запрашиваемый объект изменился (например, добавилась новая статья), объект в кеше нужно пересоздать, иначе пользователям будет отправляться неактуальная информация. Хорошие плагины настроены на авто обновление кеша при наиболее очевидных событиях. И всегда должна быть возможность сбросить кеш целиком вручную. Это как стоп-кран в поезде – очень редко, но нужен.
    • Exclude (добавление исключений) Иногда нужно исключать некоторые объекты и страницы из кеширования для устранении проблем. Должно быть достаточное управление этим.

Изменяемые файлов

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

Лучше всего использовать последовательные числа ( версии), и при каждом изменении просто увеличивать их на единицу:

Benefits of immutable

In terms of the benefits of using the directive, there are two major advantages.

  1. Better performance for the user — Since the browser doesn’t need to check the server to verify whether or not the asset is still valid, the static assets can be delivered faster from the browser cache.
  2. Less bandwidth usage — Since the browser doesn’t need to check with the server regarding whether or not the asset is still valid, this means less network bandwidth is consumed.

Facebook was amongst the first to adopt the directive. The concern of decreased performance due to conditional revalidation was a major issue for them as with a social network like Facebook, users are refreshing the page quite often to see the latest updates. Since the page is being constantly refreshed and although many static assets return a (about 20% of their assets), the browser still needed to check the server side to verify whether or not the assets changed since the last time they were accessed.

However, since implementing the directive, Facebook was able to prevent the browser from constantly checking the server thus improving performance and decreasing bandwidth usage.


С этим читают