Как настроить кэширование на сайте: пошаговая инструкция

Шаг 0. Замерить скорость до изменений

Без замера «до» невозможно понять, сработала ли настройка — это база любой оптимизации. Открыть сайт в PageSpeed Insights (pagespeed.web.dev) или GTmetrix, зафиксировать три показателя: время до первого байта (TTFB), общее время загрузки и оценку по Core Web Vitals. Проверить нужно и главную, и одну внутреннюю страницу — они могут вести себя по-разному, особенно если внутренняя страница тяжелее по контенту. Сохранить скриншот результата — он понадобится для сравнения на последнем шаге.

Шаг 1. Включить серверный кэш страниц

Это даёт основной эффект по скорости, поэтому идёт первым. На WordPress — установить плагин кэширования (WP Rocket, WP Super Cache или другой — подробный разбор выбора в отдельном материале) и включить базовый page cache в настройках. На других CMS — искать встроенный модуль кэширования в административной панели (у большинства современных систем он есть) либо уточнить у хостинг-провайдера, поддерживается ли серверное кэширование на уровне хостинга (Varnish, LiteSpeed Cache, Redis). После включения — открыть сайт в режиме инкогнито дважды подряд и сравнить время ответа: второй раз должен быть заметно быстрее, если кэш подключился.

Шаг 2. Настроить заголовки для статических файлов

Картинки, шрифты, CSS и JS-файлы должны отдаваться с заголовком Cache-Control: public, max-age=31536000 (год) при условии, что при изменении файла меняется и его имя или версия в URL (например, style.css?v=2) — иначе браузер будет год показывать старую версию изменённого файла. На Apache это делается через .htaccess директивой ExpiresByType, на Nginx — через блок location с expires в конфиге сервера. Если правка серверных конфигов недоступна напрямую (виртуальный хостинг), эту настройку обычно берёт на себя плагин кэширования или сам хостинг — стоит проверить заголовки через вкладку Network в браузере после включения кэш-плагина, прежде чем лезть в конфигурацию сервера самостоятельно.

Шаг 3. Исключить из кэша динамические страницы

Корзина, оформление заказа, личный кабинет, страница с формой обратной связи с индивидуальным ответом — всё это должно быть исключено из page cache, иначе один посетитель рискует увидеть содержимое сессии другого. В большинстве плагинов кэширования это поле называется «Never Cache URLs» или «Exclude URLs» — туда прописываются пути вида /cart/, /checkout/, /my-account/. После настройки нужно проверить эти страницы вручную под двумя разными сессиями (например, обычное окно и окно инкогнито) — убедиться, что данные не пересекаются.

Шаг 4. Включить сжатие Gzip или Brotli

Сжатие — не то же самое, что кэширование, но обычно настраивается на этом же шаге и тем же плагином или в том же конфиге сервера. Brotli эффективнее Gzip на 15-20% по итоговому размеру файла, но Gzip поддерживается везде без исключений — если хостинг не поддерживает Brotli, достаточно Gzip. Проверить, включено ли сжатие, можно на сайте вроде GiftOfSpeed compression test или той же вкладке Network — заголовок Content-Encoding должен показывать gzip или br.

Шаг 5. Подключить CDN — по необходимости, не по умолчанию

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

Шаг 6. Проверить результат и настроить очистку кэша при обновлениях

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

Таблица: контрольный список по шагам