Как настроить Redis Object Cache в WordPress

Redis object cache имеет смысл не на каждом сайте, а там, где WordPress много раз за запрос ходит в базу за одними и теми же данными: меню, настройки темы, данные плагинов, объекты WP_Query, фрагменты админки. Если страница генерируется медленно из-за повторяющихся запросов, постоянный кэш объектов может снять часть нагрузки. Но если проблема в тяжёлых SQL, плохой теме или лишних плагинах, Redis сам по себе не спасёт — он только ускорит повторное получение уже запрошенных данных.

Ниже — рабочий сценарий: как понять, нужен ли Redis, как подключить его в WordPress, как проверить, что кэш реально работает, и какие ошибки чаще всего ломают ожидания.

Когда Redis object cache действительно нужен

Ставить его «на всякий случай» не стоит. Для небольшого сайта с редкими запросами и нормальным хостингом эффект может быть почти незаметен. Зато на сайтах с большим количеством однотипных обращений к базе Redis часто помогает снизить число запросов к MySQL и разгрузить сервер.

Типичные признаки, что кэш объектов пригодится

• страницы в админке открываются заметно медленнее после роста числа плагинов;
• в Query Monitor видно много повторяющихся запросов к одним и тем же таблицам;
• на сайте есть сложные меню, виджеты, фильтры, блоки с динамическими данными;
• хостинг поддерживает Redis на уровне сервера, а не через костыли в PHP;
• объектный кэш нужен для нескольких сайтов на одном сервере, где база уже становится узким местом.

Когда лучше не начинать с Redis

Если у вас:

• медленный внешний API в теме или плагине;
• тяжёлые изображения без оптимизации;
• неправильно настроенный page cache;
• много запросов из-за кривого шаблона;

то сначала чинят эти вещи. Redis не ускоряет внешний HTTP-запрос и не исправляет плохой код, который каждый раз строит один и тот же тяжёлый SQL.

Диагностика: как понять, что проблема именно в объектных запросах

Перед внедрением полезно посмотреть, что именно тормозит. Самый простой способ — временно включить Query Monitor и открыть проблемную страницу. Смотрите не только общее время генерации, но и количество повторяющихся запросов, а также запросы, которые выполняются много раз в одном хите.

Если у вас есть доступ к серверу, можно сравнить нагрузку до и после включения object cache по таким признакам:

• уменьшается число обращений к MySQL на один запрос страницы;
• в логах или мониторинге падает среднее время ответа при одинаковой нагрузке;
• в админке меньше «подвисаний» на страницах со списками записей и метабоксами.

Важно: Redis object cache — это persistent object cache, а не page cache. Он не заменяет кэш страниц в Nginx, LiteSpeed Cache, WP Super Cache или аналогах. Эти уровни работают по-разному и часто дополняют друг друга.

Пошаговая настройка Redis object cache

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

Шаг 1. Убедиться, что Redis доступен

На сервере должен быть запущен Redis и PHP должен иметь доступ к нему через расширение phpredis или через совместимый слой. На практике чаще используют именно phpredis, потому что он быстрее и стабильнее для object cache.

Если есть SSH-доступ, можно проверить Redis так:

redis-cli ping

Ожидаемый ответ — PONG. Если команды нет, это не проблема WordPress, а вопрос настройки сервера.

Шаг 2. Установить плагин для persistent object cache

Для WordPress обычно используют плагин Redis Object Cache от Till Krüss. Он не выдуманный, широко применяется и умеет подключать persistent object cache без ручной сборки собственного drop-in.

После установки и активации плагина в админке появится кнопка включения object cache. На некоторых хостингах плагин сам подхватывает настройки Redis, если сервер уже подготовлен.

Шаг 3. Проверить wp-config.php

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

define( 'WP_CACHE', true );
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'site1:' );

Если Redis работает не на localhost, а на отдельном хосте или сокете, параметры будут другими. Не копируйте пример бездумно: проверьте, что именно указал ваш хостинг.

Шаг 4. Активировать object cache в плагине

После сохранения настроек включите persistent object cache в интерфейсе плагина. Если всё в порядке, WordPress создаст drop-in object-cache.php в wp-content. Это нормальное поведение: именно этот файл перехватывает стандартный объектный кэш WordPress.

Шаг 5. Настроить префикс и разделение окружений

Если на одном Redis-сервере живут несколько сайтов, префикс обязателен. Иначе можно получить пересечение ключей, странные данные в кэше и трудноуловимые баги. Для staging и production лучше использовать разные префиксы и, по возможности, разные базы Redis.

Как проверить, что Redis реально работает

После включения не ограничивайтесь тем, что плагин показывает зелёный статус. Проверьте несколько вещей одновременно.

• В админке плагина должен быть статус Connected или аналогичный.
• В wp-content должен появиться object-cache.php.
• В Query Monitor должно стать меньше одинаковых запросов на повторных загрузках одной и той же страницы.
• Если есть доступ к Redis CLI, можно посмотреть, растёт ли число ключей для сайта.

Полезно сравнить поведение до и после на одной и той же странице, а не на разных URL. Иначе вы легко спутаете эффект Redis с обычным page cache или случайной разницей в шаблоне.

Проверка через WP-CLI

Если на сервере доступен WP-CLI, можно хотя бы убедиться, что drop-in подключён:

wp eval 'global $wp_object_cache; var_dump( is_object( $wp_object_cache ) );'

Это не полноценный бенчмарк, но быстрый способ понять, что объектный кэш инициализируется.

Частые ошибки и как их исправить

Redis включили, а сайт не ускорился

Чаще всего причина в том, что узкое место не в object cache. Проверьте тяжёлые запросы, внешние API, отсутствие page cache и перегруженные шаблоны. Если один и тот же запрос строится каждый раз по-разному, Redis не сможет его переиспользовать.

После включения появились странные данные в админке

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

Плагин пишет, что подключение есть, но drop-in не работает

Проверьте права на wp-content, наличие файла object-cache.php и отсутствие другого object cache drop-in. Иногда старый файл от другого плагина остаётся в каталоге и перехватывает кэш раньше нужного.

Сайт начал падать после включения Redis

Это может быть проблема с неверным хостом, портом, паролем или недоступностью Redis на сервере. В таком случае временно отключите плагин, удалите drop-in и верните сайт в рабочее состояние, а потом уже разбирайтесь с серверной конфигурацией.

Практические советы по безопасности и производительности

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

• не используйте один и тот же префикс для разных сайтов;
• не храните в Redis секреты приложения, если для этого нет отдельной причины;
• после миграции или смены домена очищайте object cache;
• не смешивайте экспериментальные плагины кэша с production без теста на staging;
• если сайт маленький, не усложняйте стек без измеримой причины.

Если нужен не только object cache, но и чистка технического мусора, отключение лишних дублей и контроль SEO-поведения, иногда удобнее закрыть часть задач на уровне одного инструмента вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но Redis и такие плагины решают разные задачи, их не стоит путать.

Что проверить после внедрения на боевом сайте

После включения кэша не полагайтесь только на один показатель. Пройдитесь по короткому чек-листу:

• открывается главная страница и несколько внутренних URL;
• работает вход в админку и сохранение записей;
• не сломались формы, AJAX и REST API;
• в логах нет ошибок подключения к Redis;
• после очистки кэша сайт восстанавливает работу без ручных правок.

Если всё это проходит, Redis object cache можно считать внедрённым корректно. Дальше уже имеет смысл смотреть на реальные метрики сервера и решать, нужен ли дополнительный page cache, оптимизация запросов или чистка плагинов.