Коротко. Из всех настроек кэширования реальный прирост скорости дают три: браузерный кэш статики со сроком от 1 года (Cache-Control: max-age=31536000) при версионировании файлов, серверный page cache, убирающий повторную сборку HTML (даёт основной эффект — обычно в разы к TTFB), и OPcache для PHP с адекватным объёмом памяти (по умолчанию часто занижен до 128 МБ). CDN и минификация ускоряют дополнительно, но без первых трёх настроек погоды не делают.
Три уровня, на которых работает кэш
Кэширование сайта — это не одна настройка, а три независимых слоя, и путаница между ними — причина половины разочарований «включил кэш, а быстрее не стало». Первый слой — браузер посетителя, который может не скачивать повторно картинки, стили и скрипты при повторном визите. Второй — сервер, который может не пересобирать HTML-страницу заново на каждый запрос, а отдавать готовый файл. Третий — PHP-движок, который может не компилировать код сайта заново при каждом обращении. Каждый слой ускоряет своё, и настройка одного не заменяет два других: сайт с идеальным браузерным кэшем, но без page cache, всё равно будет медленно генерировать HTML при каждом заходе нового посетителя.
Cache-Control и Expires: какие значения реально нужны
Для статики, которая не меняется без изменения имени файла (картинки, шрифты, версионированные CSS и JS вида style.css?v=3), правильное значение — Cache-Control: public, max-age=31536000, immutable, то есть год. Это не произвольная цифра: год — практический максимум, дальше кэш всё равно сбрасывается пользователем или браузером, а более короткие сроки (неделя, месяц) заставляют браузер лишний раз проверять актуальность файла, хотя тот физически не изменился. Для HTML-страниц ситуация обратная: длинный кэш опасен, потому что посетитель увидит старую версию после правки контента. Для HTML разумный диапазон — от no-cache (проверка при каждом обращении) до нескольких минут на страницах, которые обновляются редко. Ставить на HTML тот же годовой срок, что и на картинки, — прямая причина жалоб «сайт не обновляется», разбор которых — тема отдельного материала об ошибках кэширования.
Серверный кэш страниц — источник основного прироста
Page cache (кэш страниц) сохраняет уже собранный HTML-ответ сервера и отдаёт его следующим посетителям без повторного обращения к базе данных и выполнения PHP-кода. Именно этот механизм даёт наибольший прирост скорости на сайтах с CMS: на WordPress без кэша сборка страницы означает десятки запросов к базе на каждый заход, с включённым page cache — ноль запросов для уже закэшированной страницы. На практике это обычно сокращает время ответа сервера (TTFB) с 500-1500 мс до 50-150 мс на типичном хостинге. Важное ограничение — page cache нельзя включать бездумно для страниц с персональным содержимым: корзина, личный кабинет, страница оформления заказа должны быть исключены из кэша, иначе один посетитель может увидеть содержимое корзины другого.
OPcache — настройка, которую чаще всего забывают
OPcache — встроенный в PHP механизм, который хранит скомпилированный байт-код скриптов в памяти, чтобы не разбирать PHP-файлы заново при каждом запросе. Он включён по умолчанию почти на всех современных хостингах, но часто с заниженными лимитами: значение opcache.memory_consumption по умолчанию — 128 МБ, чего для сайта на 200+ файлов плагинов и модулей может не хватать, из-за чего кэш постоянно перезаписывается и не даёт эффекта. Для среднего сайта на CMS разумный ориентир — 256-512 МБ, для крупного интернет-магазина с множеством модулей — выше. Проверить, работает ли OPcache и достаточно ли ему памяти, можно через phpinfo() или панель хостинга: если показатель «opcache hit rate» ниже 95%, это сигнал, что памяти не хватает и настройки нужно поднимать.
CDN и edge-кэширование
CDN (сеть доставки контента) кэширует статику на серверах, географически близких к посетителю, и здесь эффект напрямую зависит от географии аудитории: для сайта, который читают в основном из Москвы и на сервере в Москве, CDN даст минимальный прирост в единицы миллисекунд. Для сайта с аудиторией по всей России или за рубежом — эффект куда заметнее, поскольку убирает задержку доставки данных на дальние расстояния. CDN стоит рассматривать не как обязательный, а как дополнительный слой поверх уже настроенного браузерного и серверного кэша — сам по себе, без них, он ускоряет только доставку статики, но не решает проблему медленной генерации HTML.
Что не даёт реального эффекта, хотя выглядит как оптимизация
Минификация HTML/CSS/JS (удаление пробелов и переносов строк) экономит доли процента от размера файла — в 2026 году при современных каналах связи это заметно на глаз только через синтетические тесты вроде PageSpeed Insights, но почти не влияет на реальное время загрузки для посетителя с обычным интернетом. Объединение файлов CSS/JS в один (конкатенация) было важно во времена HTTP/1.1 с ограничением на число параллельных соединений — при HTTP/2, который сейчас использует подавляющее большинство хостингов, параллельные запросы не блокируют друг друга, и объединение файлов иногда даже вредит, потому что браузер не может закэшировать один маленький изменившийся файл отдельно от остальных. Включать эти настройки можно, но ожидать от них решающего прироста не стоит — основной эффект дают именно первые три уровня.
Как проверить, что настройки реально работают
Первая проверка — заголовки ответа сервера через вкладку Network в инструментах разработчика браузера: у статики должен быть виден Cache-Control с большим max-age, у повторного запроса статус 304 (Not Modified) или запрос вовсе не уходит на сервер. Вторая — сравнение времени ответа первого и второго захода на одну и ту же страницу: разница в разы говорит о том, что page cache действительно подключился. Третья — синтетические тесты PageSpeed Insights, GTmetrix или WebPageTest, где стоит смотреть не только на итоговую оценку, а на конкретный показатель TTFB (время до первого байта) — именно он показывает, работает ли серверный кэш. Проверка настроек кэша — стандартная часть SEO-аудита, поскольку скорость напрямую входит в число факторов ранжирования.
С чего начать настройку кэширования, если ничего ещё не сделано?
С серверного page cache — он даёт основной эффект. На WordPress это плагин кэширования (см. отдельный разбор), на других CMS — либо встроенный механизм, либо настройка на уровне хостинга (Varnish, LiteSpeed Cache). После него — заголовки Cache-Control для статики, и только затем — CDN и минификация.
Сколько времени занимает настройка кэширования сайта?
Базовая настройка через готовый плагин или панель хостинга — 30-60 минут, включая тестирование, что ничего не сломалось. Тонкая настройка с исключениями для динамических страниц, проверкой OPcache и CDN — от нескольких часов до дня, в зависимости от сложности сайта.
Можно ли настроить кэширование самостоятельно, без разработчика?
Базовый уровень — да, особенно на WordPress через готовый плагин с настройками по умолчанию. Тонкую настройку (исключения для корзины и личного кабинета, лимиты OPcache, работа с CDN) без технического опыта делать рискованно — ошибка может привести к показу чужих персональных данных другому посетителю.
Почему после настройки кэша сайт не стал заметно быстрее?
Чаще всего причина в том, что настроен только один уровень (например, только браузерный кэш через .htaccess) без серверного page cache, который даёт основной прирост. Второй частый случай — узкое место не в кэшировании, а в тяжёлых изображениях без сжатия или в стороннем коде (виджеты, счётчики), которые кэш не ускоряет.
Нужен ли CDN небольшому региональному сайту?
Как правило нет, если сервер и аудитория находятся в одном регионе — прирост будет в пределах десятков миллисекунд. Приоритет для такого сайта — серверный кэш и OPcache, они дают эффект на порядок заметнее.
Проверить, как настроено кэширование на сайте
Смотрим заголовки, page cache, OPcache и находим, что реально тормозит загрузку — не только на бумаге, а по факту замеров.