Кэширование ресурсов Cotonti: как включить и как выключить

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

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

Google Pagespeed, например, рекомендует кэшировать типовые ресурсы сроком на год.

Что делать в таких случаях? Прежде всего, разделим проблему на две части:

1. Тестирование и отладка изменений.
2. Учет измененных ресурсов при их отдаче клиенту.

Напомним, что в системе Cotonti, в зависимости от решения разработчика, ресурсы отдаются либо “вверху”, либо “внизу”:

// Файл стилей загрузится "вверху", т. е. в контейнере head
Resources::linkFile($cfg['themes_dir'] . '/' . $usr['theme'] . '/css/preloader.css', 'css', 1);
// Файл скриптов загрузится "внизу", т. е. перед закрывающим </body>
Resources::linkFileFooter($cfg['themes_dir'] . '/' . $usr['theme'] . '/js/preloader.js', 'js', 101);

Вся эта история указывается в PHP-файле темы (например, nemesis.php), либо в PHP-файлах, подгружаемых функцией cot_incfile():

// Будет подгружен файл themes/nemesis/nemesis.pagination.php
require_once cot_incfile('nemesis', 'theme', 'pagination');

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

Resources::linkFileFooter($cfg['themes_dir'] . '/' . $usr['theme'] . '/css/custom.css?v=520', 'css', 62);

Обычно ресурсов подгружается немало, поэтому имеет смысл ввести переменную с номером версии:

$theme_version = 520;
Resources::linkFileFooter($cfg['themes_dir'] . '/' . $usr['theme'] . '/css/custom.css?v=' . $theme_version, 'css', 62);
Resources::linkFileFooter($cfg['themes_dir'] . '/' . $usr['theme'] . '/css/responsive.css?v=' . $theme_version, 'css', 63);

Уже лучше. Но при отладке изменений на удаленном сервере каждый раз придется изменять значение параметра v. Чтобы избежать этого используем timestamp – целое количество секунд, прошедших с 01.01.1970 UTC. Именно то, что нам необходимо:

// $theme_version = 187;
$theme_version = Cot::$sys['now'];

Почему явно указанную версию я закомментировал? Если оставить на работающем проекте вариант с Unix timestamp, кэширование будет фактически отключено. Так что в работе нам понадобятся оба варианта.

Резюмируем:

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

Таким образом, при отладке необходимо лишь закомментировать строку с явным указанием и раскомментировать строку с Unix timestamp.

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

Предыдущая публикация была посвящена вопросам получения,  проверки и кэширования внешних JSON-данных.