Кэширование в WordPress: обзор способов

Кэширование — самый дешёвый способ ускорить сайт на WordPress. Не нужно переписывать тему, переезжать на другой хостинг или выкидывать половину плагинов: достаточно перестать пересчитывать одно и то же по сто раз в минуту. Сложность в другом — словом «кэш» в WordPress называют минимум пять разных механизмов, которые живут на разных уровнях, настраиваются по-разному и решают разные задачи. Ниже — разбор всех способов: что за что отвечает, чем отличаются популярные плагины, что можно включить на стороне сервера и что кэшировать нельзя ни при каких условиях.

Почему WordPress вообще нужно кэшировать

Каждый запрос к некэшированной странице запускает длинную цепочку. Веб-сервер передаёт запрос в PHP, PHP поднимает ядро WordPress, подключает активные плагины и файлы темы, выполняет десятки запросов к MySQL, собирает HTML и отдаёт его браузеру. На типичном сайте с десятком-двумя плагинов это 200–800 мс работы только на стороне сервера — и так для каждого посетителя, хотя результат у всех получается совершенно одинаковый.

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

Побочный эффект не менее важен, чем скорость: кэш снимает нагрузку. Сайт, который на «голом» WordPress ложится от 50 одновременных посетителей, с настроенным кэшем страниц спокойно держит несколько тысяч. Если вы уже проходили общий чек-лист оптимизации WordPress, кэширование — тот его пункт, который даёт самый заметный прирост за самое короткое время.

Пять уровней кэша: что где живёт

1. Кэш страниц (page cache)

Самый мощный тип. Плагин один раз собирает страницу и сохраняет готовый HTML — в файл на диске или в память. Все последующие посетители получают этот файл, минуя PHP и базу данных полностью или почти полностью. Именно кэш страниц превращает 600 мс в 30 мс.

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

2. Объектный кэш (object cache)

WordPress внутри себя постоянно спрашивает базу об одном и том же: настройки, метаполя записей, термины таксономий. Объектный кэш (класс WP_Object_Cache) запоминает эти ответы. По умолчанию он непостоянный — живёт ровно один HTTP-запрос и умирает вместе с ним. Постоянный объектный кэш подключается drop-in-файлом wp-content/object-cache.php и хранит данные в Redis или Memcached между запросами.

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

3. Кэш запросов к базе и фрагментов

Кэш базы данных сохраняет результаты отдельных SQL-запросов, фрагментный кэш — куски готовой разметки (меню, сайдбар, блок «популярное»). Оба механизма имеют смысл там, где страницу целиком закэшировать нельзя, но большая её часть всё-таки одинакова для всех.

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

4. OPcache — кэш байт-кода PHP

Про него часто забывают, хотя он бесплатный и почти всегда уже есть. OPcache — расширение самого PHP: оно компилирует php-файлы в байт-код один раз и держит результат в памяти, вместо того чтобы разбирать тысячи файлов ядра и плагинов при каждом запросе. Прирост на WordPress — десятки процентов времени генерации страницы.

Настраивается не в плагине, а в конфигурации PHP: opcache.enable=1, разумный opcache.memory_consumption (128–256 МБ для крупного сайта) и opcache.max_accelerated_files не ниже 10000 — WordPress с плагинами легко выходит за стандартные лимиты.

5. Кэш браузера и CDN

Самый внешний слой. Заголовки Cache-Control и ETag говорят браузеру хранить картинки, шрифты, CSS и JS локально — повторный визит не тянет их заново. CDN делает то же самое, но для всех посетителей сразу и на серверах, физически близких к ним. Современные CDN умеют кэшировать не только статику, но и HTML: например, Cloudflare APO держит страницы WordPress прямо на своих узлах. Для сайтов на бесплатном тарифе это платная опция за 5 долларов в месяц, во всех платных тарифах она включена.

Плагины кэширования: чем отличаются

WP Super Cache

Плагин от Automattic, разработчиков самого WordPress: больше миллиона установок, версия 3.1.1 от мая 2026 года. Делает одно дело — кэш страниц в статические HTML-файлы — и делает его надёжно. Три режима отдачи: «экспертный» через правила mod_rewrite в Apache (PHP не участвует вообще), «простой» через PHP и режим WP-Cache для страниц с персонализацией.

Кому подойдёт: небольшой блог или корпоративный сайт на обычном хостинге, где нужен результат без настроек. Чего не умеет: объектного кэша, оптимизации CSS/JS и картинок здесь нет.

W3 Total Cache

Ветеран с более чем 900 тысячами установок, актуальная версия 2.10.4. Единственный из массовых плагинов, который закрывает все уровни сразу: страницы, объектный кэш, база, фрагменты, минификация, интеграция с CDN и работа с OPcache. Каждый модуль умеет писать в диск, Redis, Memcached или APCu.

Обратная сторона гибкости — количество настроек. Неаккуратная конфигурация ломает вёрстку минификацией или отдаёт залогиненному пользователю чужую страницу. Кому подойдёт: тем, кто готов разобраться и хочет один инструмент на все слои.

LiteSpeed Cache

Самый популярный на сегодня — более 7 миллионов активных установок, версия 7.9 вышла 5 августа 2026 года. Ключевая особенность: кэш страниц реализован на уровне веб-сервера LiteSpeed или OpenLiteSpeed, а не в PHP. Плагин лишь управляет им, поэтому отдача страниц происходит ещё до запуска интерпретатора.

На LiteSpeed-сервере доступны приватный кэш для залогиненных пользователей, кэширование REST API, раздельные версии для мобильных и десктопа, корректная работа с WooCommerce. На Apache или nginx плагин тоже устанавливается, но «серверная» часть отключается — остаются общие функции: оптимизация изображений, критический CSS, ленивая загрузка, чистка базы, бесплатный CDN QUIC.cloud.

Кому подойдёт: всем, чей хостинг работает на LiteSpeed (а это большинство массовых тарифов) — бесплатно и очень быстро. На других серверах смысл теряется наполовину.

WP Rocket

Единственный в подборке платный: 59 долларов в год за один сайт, 119 за три и 299 за пятьдесят, с автопродлением и возвратом в течение 14 дней. Продаётся не функциями, а тем, что после активации почти всё уже настроено правильно: кэш страниц, предзагрузка, отложенный JavaScript, ленивая загрузка, оптимизация базы.

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

Короткий выбор

Хостинг на LiteSpeed — берите LiteSpeed Cache и не думайте. Обычный Apache/nginx и простой сайт — WP Super Cache. Нужен контроль над всеми слоями и есть время — W3 Total Cache. Нужен результат «из коробки» и есть бюджет — WP Rocket. Главное правило: только один плагин кэширования страниц. Два одновременно — это не двойная скорость, а гарантированные конфликты и невалидируемый кэш.

Кэш на стороне сервера

Плагин — не единственный вариант. На nginx кэш страниц включается через fastcgi_cache, на Apache — через mod_cache, перед сайтом можно поставить Varnish. Такой кэш быстрее любого плагина, потому что PHP вообще не запускается.

Плата за скорость — сложность инвалидации: сервер не знает, что вы отредактировали запись, и продолжает отдавать старую версию. Поэтому серверный кэш почти всегда настраивают в паре с плагином-«очистителем», который посылает запрос на сброс нужных URL при сохранении контента.

Если у вас управляемый WordPress-хостинг, серверный кэш, скорее всего, уже включён провайдером — и тогда ставить сверху ещё один плагин кэша страниц не нужно. Уточните в поддержке, прежде чем настраивать.

Объектный кэш на Redis: когда он нужен

Плагин Redis Object Cache (более 400 тысяч установок, версия 2.8.0) подключает Redis как хранилище постоянного объектного кэша — через drop-in object-cache.php. Есть и коммерческая версия Object Cache Pro с более быстрой сериализацией и отдельными оптимизациями под WooCommerce.

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

Два подводных камня. Первый: Redis должен быть установлен на сервере, и к нему нужно PHP-расширение (PhpRedis или Predis) — на дешёвом шаред-хостинге этого часто нет. Второй: ограничьте память Redis и задайте политику вытеснения allkeys-lru, иначе кэш разрастётся и упрётся в лимит.

Что кэшировать нельзя

Самые дорогие аварии в кэшировании — не про скорость, а про то, что один посетитель увидел данные другого. Из кэша страниц всегда исключаются:

• корзина, оформление заказа и личный кабинет в WooCommerce (/cart/, /checkout/, /my-account/);
• любые страницы для авторизованных пользователей и вся админка;
• формы с CSRF-токенами и капчей — закэшированный токен просто перестанет проходить проверку;
• страницы результатов поиска и URL с параметрами вроде ?utm_source=, если только вы не настроили игнорирование этих параметров;
• динамические блоки: счётчики, «последние комментарии», персональные рекомендации — их выносят в AJAX-запрос или фрагментный кэш.

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

Как проверить, что кэш работает

Не верьте галочке в настройках — проверяйте ответом сервера. Откройте инструменты разработчика, вкладку «Сеть», и посмотрите заголовки главного документа: там должно быть что-то вроде x-litespeed-cache: hit, x-cache: HIT или cf-cache-status: HIT. То же самое из консоли: curl -I https://ваш-сайт.ру/.

Второй показатель — TTFB, время до первого байта. Загрузите страницу дважды: первый раз кэш собирается, второй должен отдаться заметно быстрее. Разница в 5–20 раз — норма для работающего кэша страниц.

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

Пять типичных ошибок

1. Два плагина кэша страниц сразу. Классика «на всякий случай»: WP Rocket поверх LiteSpeed Cache или W3TC рядом с WP Super Cache. Результат — конфликты и непредсказуемая инвалидация.
2. Кэш есть, а сброса нет. Обновили цену товара — а посетители неделю видят старую. Настройте автоматическую очистку при сохранении записи и после деплоя.
3. Агрессивная минификация без проверки. Объединение JS ломает скрипты чаще, чем ускоряет сайт. Включайте по одному пункту и проверяйте формы, слайдеры и корзину.
4. Слишком долгий TTL для HTML. Для статики месяц — норма, для HTML сутки-двое обычно предел.
5. Кэш вместо оптимизации. Кэш прячет медленный код, но не лечит его. Первый визит, редкие страницы и админка останутся медленными, пока не разобраны тяжёлые запросы и лишние плагины.

Вывод

Рабочая схема для большинства сайтов складывается из четырёх слоёв: OPcache на уровне PHP (почти всегда уже включён), один плагин кэша страниц под ваш тип сервера, объектный кэш в Redis — если сайт нагруженный или это магазин, и CDN с кэшем статики поверх всего. Плюс аккуратный список исключений для корзины, кабинета и админки.

Начните с кэша страниц: он даёт 80% результата за 20 минут. Остальное добавляйте по мере роста нагрузки — и каждое изменение проверяйте заголовками ответа, а не ощущениями. Кстати, кэш давно вышел за пределы веб-серверов: в работе с языковыми моделями кэширование промптов экономит деньги ровно по той же логике — не пересчитывать то, что уже посчитано.