Кеширование WordPress: как выбрать плагин и не сломать сайт

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

Меня зовут Андрей Зенков, я руковожу веб-студией «Мельница» и с 2013 года занимаюсь оптимизацией сайтов для бизнеса. В этой статье разберу, как правильно выбрать способ кеширования для WordPress: какие плагины использовать, чем отличаются page cache и object cache, и как не наступить на типичные грабли при настройке.

По моей практике, для большинства сайтов на WordPress достаточно связки WP Rocket (page cache) + Redis (object cache) - это снижает нагрузку на сервер в 5-10 раз и уменьшает время загрузки страниц с 3-5 секунд до 0.5-1 секунды без смены хостинга (результат зависит от конфигурации сервера и сайта).

Статья рассчитана на владельцев сайтов и разработчиков, работающих со стеком WordPress на обычном VPS или shared-хостинге. Я не буду касаться CDN как отдельного инструмента и enterprise-решений на базе Varnish - это отдельные темы. Здесь только то, что реально настраивается руками за один вечер.

Почему WordPress тормозит без кеширования

WordPress - динамическая CMS. Это означает, что каждый раз, когда посетитель открывает любую страницу, PHP-интерпретатор запускает цепочку процессов: подключается к базе данных, выполняет десятки SQL-запросов, собирает данные из разных таблиц, передаёт их в шаблон и формирует HTML-ответ. Весь этот процесс повторяется для каждого посетителя, при каждом обновлении страницы - независимо от того, изменилось ли содержимое сайта с прошлого раза.

На малом трафике это незаметно. Но стоит нагрузке вырасти - и сервер начинает захлёбываться. На сайте в моей практике с 500 одновременными посетителями без кеша MySQL получал свыше 2000 запросов в секунду только от WordPress - с учётом AJAX, виджетов и повторных обращений браузера к динамическим данным. Размер очереди к базе рос быстрее, чем сервер успевал её обрабатывать.

Здесь важно понять: у WordPress есть две отдельные проблемы, которые решаются разными способами.

Первая - генерация HTML. Каждый раз, когда страница запрашивается, PHP собирает её с нуля. Это дорого по времени и по ресурсам процессора. Решение - сохранить готовую HTML-страницу и отдавать её без повторной генерации.

Вторая - запросы к базе данных. Даже если HTML уже собран, WordPress в процессе работы постоянно обращается к базе за отдельными данными: настройки, виджеты, метаданные записей, опции плагинов. Эти запросы можно кешировать на уровне приложения, не трогая готовые страницы.

Понимание этого разделения - ключ к тому, чтобы использовать кеширование правильно. Большинство начинающих устанавливают один плагин и считают, что «кеш включён». На практике они решают только первую проблему, а вторая остаётся нерешённой.

Два уровня кеширования: page cache и object cache

Page cache - это сохранение готовой HTML-страницы на диск или в память. Когда следующий посетитель запрашивает ту же страницу, сервер отдаёт сохранённую копию без запуска PHP и без обращений к базе. Это самый очевидный и мощный способ ускорить сайт: вместо 300-500 мс на генерацию страница отдаётся за 5-20 мс.

Object cache - это кеширование результатов отдельных запросов к базе данных прямо в памяти сервера. WordPress имеет встроенный механизм object cache, но по умолчанию он работает только внутри одного запроса и сбрасывается после его завершения. Подключив Redis или Memcached, мы делаем этот кеш персистентным - данные живут между запросами и не запрашиваются из базы заново.

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

Параметр	Page Cache	Object Cache
Что кешируется	Готовый HTML всей страницы	Результаты отдельных запросов к БД
Где хранится	Файловая система или RAM	Redis, Memcached или RAM
Для чего	Статичный контент: записи, страницы	Динамические данные: настройки, опции, метаданные
Эффект	Снижает нагрузку на PHP и MySQL в 5-20 раз	Сокращает количество SQL-запросов на 30-70%
Работает для авторизованных	Как правило, нет	Да
Размер данных	Большой (полные страницы)	Малый (отдельные значения)

На практике я всегда включаю оба уровня. Page cache даёт максимальный эффект для анонимных посетителей - а это 90%+ трафика большинства блогов и корпоративных сайтов. Object cache критически важен для интернет-магазинов на WooCommerce и сайтов с авторизацией: там page cache не применяется к страницам корзины и профиля, но object cache всё равно снижает нагрузку на базе.

Важный нюанс: в WordPress эти уровни реализуются через разные настройки и разными инструментами. Плагины вроде WP Rocket или WP Super Cache отвечают преимущественно за page cache. Redis или Memcached - за object cache. Понимание этого разделения поможет правильно использовать каждый инструмент и не ждать от одного плагина решения всех проблем сразу.

Выбор способа кеширования: файловый кеш, Redis или Memcached

Когда клиент спрашивает, какой способ кеширования выбрать - файловый, Redis или Memcached - я всегда начинаю с вопроса: «На каком хостинге стоит сайт?». Ответ на него определяет всё остальное.

Файловый кеш - самый простой вариант. Плагин генерирует HTML и сохраняет его в папку wp-content/cache. При следующем запросе сервер отдаёт готовый файл, минуя PHP и базу данных. Никаких дополнительных сервисов устанавливать не нужно - включите плагин, и всё заработает. Скорость отдачи чуть ниже, чем у in-memory решений, но для небольших сайтов с трафиком до нескольких тысяч посетителей в день этого вполне достаточно. Работает на любом хостинге, даже на shared-тарифах.

Redis - in-memory хранилище с поддержкой сложных структур данных и персистентностью: данные сохраняются при перезапуске сервера. Это лучший выбор для object cache, а на VPS его можно использовать и для page cache. Подходит для интернет-магазинов на WooCommerce, сайтов с высокой нагрузкой и сетях серверов с общей памятью. Многие хостинги на тарифах VPS и выше предлагают Redis из коробки - проверьте панель управления, прежде чем что-то устанавливать отдельно.

Memcached - более простое in-memory хранилище. Очень быстрое, но без сохранения данных при перезапуске. На практике для большинства WordPress-проектов Redis предпочтительнее: он умеет больше при сопоставимой скорости.

Мой практический совет: на shared-хостинге - только файловый кеш, на VPS с трафиком от 10 000 визитов в день или с WooCommerce - Redis для object cache обязательно, файловый или Redis для page cache по обстоятельствам. Memcached рассматривайте только если Redis недоступен на вашем сервере.

Лучшие плагины для кеширования WordPress

За годы работы в студии мы перепробовали большинство решений. Сейчас у нас устоявшийся список из четырёх плагинов - выбор зависит от задачи и уровня клиента.

WP Super Cache - бесплатный плагин от Automattic, один из самых популярных на WordPress.org. Настроить его можно за пять минут, интерфейс понятными шагами ведёт через процесс. Умеет только page cache, опции минимальны. Хороший старт для простого сайта на shared-хостинге.

W3 Total Cache - бесплатный, очень гибкий инструмент. Этот плагин охватывает практически всё: page cache, object cache, database cache, интеграцию с CDN, минификацию, поддержку Redis и Memcached. Но за гибкость приходится платить сложностью - без технического понимания легко включить опцию, которая сломает сайт. Использую его на проектах, где нужна тонкая настройка.

WP Rocket - платный плагин (цена актуальна на момент написания - около $59 в год), который я рекомендую большинству клиентов. По моему опыту, один из лучших вариантов page cache: результат сильный, а разобраться просто. Интерфейс сделан с понятными подсказками, технических знаний не требует. Включите его - и большинство настроек уже выставлены оптимально. Окупается за счёт экономии времени на разбирательствах с конкурентами.

LiteSpeed Cache - бесплатный, но работает только на серверах с LiteSpeed Web Server. Если ваш хостинг его поддерживает - это самый быстрый вариант из доступных, использует возможности сервера на уровне, недоступном другим плагинам.

Плагин	Цена	Тип кеша	Сложность	Для кого
WP Super Cache	Бесплатно	Page cache	Низкая	Новички, простые сайты
W3 Total Cache	Бесплатно	Полный стек	Высокая	Разработчики, сложные проекты
WP Rocket	~$59/год	Page cache + доп. оптимизация	Низкая	Бизнес-сайты, клиенты без техника
LiteSpeed Cache	Бесплатно	Полный стек	Средняя	Только серверы с LiteSpeed Web Server

Типичные ошибки при настройке кеша

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

1. Кешировать страницы корзины и чекаута в WooCommerce. Это критическая ошибка. Кешированная страница корзины покажет одному из посетителей чужие данные или устаревшее содержимое. Все страницы с индивидуальным контентом - корзина, чекаут, профиль, страница заказа - должны быть в списке исключений.
2. Не настроить исключения для авторизованных пользователей. Авторизованный посетитель должен видеть персонализированный контент, а не закешированную страницу для анонима. Большинство плагинов по умолчанию это учитывают, но проверьте настройки - особенно если используете кастомные куки.
3. Не исключить /wp-admin/ и wp-cron.php. Кеширование административных запросов влияет на работу фоновых задач, рассылок, обновлений плагинов. Это не всегда очевидно - процесс на поверхности может выглядеть рабочим, но задачи будут выполняться некорректно.
4. Не настроить отдельные правила для мобильных устройств. Если мобильная версия сайта отличается от десктопной по структуре, а не только по CSS - нужен отдельный кеш для мобильных. Иначе мобильные пользователи получат десктопную страницу.
5. Неправильный TTL кеша. Слишком большой TTL - изменения на сайте не показываются посетителям часами: обновили цену, а кеш заново её не подтянул. Слишком маленький TTL - кеш удаляет данные раньше, чем они успевают принести пользу, нагрузка на сервер почти не снижается. Помимо TTL, обязательно настройте автоматическую инвалидацию кеша при обновлении записей и страниц.

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

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

HTTP-заголовки в DevTools. Самый прямой способ проверить page cache - откройте браузер, нажмите F12, перейдите во вкладку Network, обновите нужную страницу и кликните на первый запрос (сам HTML-документ). В разделе Headers ищите заголовки вида X-Cache: HIT, X-Cache-Status: HIT или X-WP-CF-Super-Cache: HIT - название зависит от плагина. HIT означает: страница отдана из кеша. MISS - страница была сгенерирована заново, кеш не сработал или ещё не прогрет.

TTFB до и после. Во вкладке Network того же DevTools видна колонка Waterfall. Загрузите страницу первый раз (MISS - первый посетитель прогревает кеш), затем обновите снова (должен быть HIT). Time to First Byte - время до первого байта ответа - с кешем сокращается в несколько раз. Типичная картина по моим наблюдениям на типичных проектах: без кеша TTFB 800-1200 мс, с файловым кешем - 80-150 мс, с Redis - ещё быстрее (реальные цифры зависят от сервера и сайта).

GTmetrix и PageSpeed Insights. Запустите тест до включения кеша, сохраните скриншот результатов, затем запустите снова после настройки. Смотрите на LCP (Largest Contentful Paint) и TTFB. Это хороший способ показать клиенту наглядный результат - цифры говорят убедительнее любых слов.

Query Monitor для object cache. Плагин Query Monitor показывает, сколько SQL-запросов выполняется при загрузке страницы. На сложном сайте без object cache это может быть 80-150 запросов. После подключения Redis число должно упасть до 10-20: большинство данных берётся из памяти, а не из базы. Процесс проверки занимает минуту - установил, открыл страницу, посмотрел на счётчик запросов в нижней панели WordPress.

На одном из клиентских проектов - интернет-магазин на WooCommerce (~800 SKU, VPS 2 vCPU / 4 GB RAM, WP Rocket + Redis) - мы включили Redis и увидели снижение SQL-запросов с 120 до 18 на странице каталога. TTFB упал с 1,1 секунды до 190 мс. Всё это легко читается в DevTools за пять минут проверки.

С чего начать: алгоритм внедрения кеша

После того как разобрались с теорией и ошибками, остаётся главный вопрос - как применить это на практике, не сломав сайт и не потратив лишнее время. Вот алгоритм, который мы в студии используем при внедрении кеша на любой платформе - от простого блога до нагруженного WooCommerce.

1. Определи тип сайта и трафик. Блог или корпоративный сайт с минимальными изменениями контента - достаточно page cache. WooCommerce, сайт с членством или личными кабинетами - нужен и object cache, иначе нагрузку на сервер снизить не получится по-настоящему.
2. Выбери хранилище под своё окружение. На shared-хостинге доступен только файловый кеш - это нормальный старт. На VPS или выделенном сервере добавь Redis для object cache: установить его на уровне сервера занимает 10-15 минут, а результат ощутим сразу.
3. Установи подходящий плагин. Начинающим подойдёт WP Rocket - он настраивает базовые опции автоматически, интерфейс с понятными шагами ведёт через весь процесс. Разработчикам, кому нужен тонкий контроль - W3 Total Cache. LiteSpeed-хостинг - только LiteSpeed Cache, он работает на уровне веб-сервера и даёт лучший результат на этой платформе.
4. Настрой исключения. Включите исключения для корзины, страницы оформления заказа, профиля пользователя, wp-admin и URL с параметрами. Это критично - если забыть, покупатели увидят чужие корзины или устаревшие цены.
5. Установи TTL разумно. Для большинства страниц - 24-72 часа. Для новостей или акций, где контент меняется часто, - 1-4 часа. Использовать одно значение для всего сайта не стоит - настрой опции по типам контента.
6. Проверь результат. DevTools + GTmetrix до и после - обязательный шаг, не пропускай. Нужно убедиться, что заголовок показывает HIT, а TTFB действительно снизился.
7. Настрой мониторинг. Раз в месяц заглядывай в PageSpeed Insights и смотри на метрики сайта. Кеш может перестать работать после обновления плагина или смены хостинга - лучше поймать это раньше, чем через полгода.

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

Начните с базового page cache - измерьте TTFB до и после. Если нагрузка растёт или на сайте есть WooCommerce, добавьте Redis для object cache. Небольшие усилия на старте избавят от серьёзных проблем при росте трафика.

Эта статья основана на личном опыте автора и актуальна на момент публикации. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.

Список литературы

1. WordPress.org - Cache - Advanced Administration Handbook // developer.wordpress.org, 2024
2. WeDevs - WordPress Object Caching: Everything You Need to Know // wedevs.com, 2023
3. CloudPanel - Redis или Memcached для WordPress: что выбрать // cloudpanel.io, 2023
4. Habr - Ускорение WordPress. Тотальный разбор плагинов для кэширования // habr.com, 2021