Redis — это in-memory база данных, которая кэширует результаты запросов WordPress к MySQL. Вместо повторных обращений к БД WordPress берёт данные из RAM — разница в скорости колоссальная.

Установка Redis на VPS (Ubuntu)

sudo apt update
sudo apt install -y redis-server

# Запустить и добавить в автозапуск
sudo systemctl enable --now redis-server

# Проверить
redis-cli ping
# PONG — всё работает

Настройка Redis для WordPress

Установить PHP расширение

sudo apt install -y php-redis
sudo systemctl restart php8.2-fpm  # или вашу версию PHP

Добавить в wp-config.php

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE', true);

Установить плагин

Установите плагин Redis Object Cache в Админ → Плагины → Добавить. После активации перейдите в Настройки → Redis и нажмите «Enable Object Cache».

✅ Статус должен показать «Connected» и «Object cache is enabled».

Результаты оптимизации

Метрика	До Redis	После Redis
TTFB	800–1200 мс	80–150 мс
Запросов к БД	80–150	5–10
Нагрузка CPU	Высокая	Низкая

⚠️ На хостинге без доступа к VPS используйте вместо Redis плагинный кэш (WP Super Cache или W3 Total Cache).

Мониторинг Redis

# Статистика
redis-cli info stats | grep -E 'hits|misses|expired'

# Очистить кэш
redis-cli flushdb

# Мониторинг в реальном времени
redis-cli monitor

Разбор ошибок подключения Redis

Object cache в WordPress зависит от трёх независимых компонентов: сервиса Redis, PHP-расширения и самого плагина. Ошибка может быть на любом из уровней.

Текст ошибки или статус	Причина	Что делать
Status: Not connected в Redis Object Cache	Служба redis-server не запущена или слушает другой адрес и порт, отличный от указанного в WP_REDIS_HOST	Проверить systemctl status redis-server и выполнить redis-cli -h 127.0.0.1 ping
PHP Fatal error: Uncaught Error: Class "Redis" not found	Расширение php-redis не установлено для той версии PHP, которая используется в пуле PHP-FPM	Выполнить php -m \| grep redis именно для рабочей версии PHP-FPM
(error) NOAUTH Authentication required	В redis.conf включён requirepass, но пароль не передан в WP_REDIS_PASSWORD	Добавить define('WP_REDIS_PASSWORD', '...') в wp-config.php
Object cache is enabled, но TTFB не изменился	Включён ещё и полный HTML-кэш другого плагина, который маскирует эффект от Redis, либо узкое место в CPU, а не в БД	Проверить redis-cli info stats на реальный hit rate

Про кэширование PHP-сессий в Redis отдельно от объектного кэша — в статье про сессии PHP в Redis.

Когда Redis не даст эффекта

Сайт на shared-хостинге без root-доступа — установить и запустить redis-server там просто негде, нужен VPS или выделенный сервер
Основная проблема — не повторяющиеся SELECT-запросы, а один медленный отчётный запрос раз в день — объектный кэш кэширует часто повторяющиеся обращения, а не разовые
Сайт с одним посетителем в час — кэш не успевает прогреться до следующего сброса и не даёт заметного эффекта
База данных уже маленькая и быстрая (до 10 000 записей) без сложных JOIN — выигрыш от Redis будет в пределах десятков миллисекунд, а не в разы
Сайт уже упирается не в базу данных, а в рендер тяжёлого визуального конструктора страниц — там эффективнее общие меры ускорения фронтенда

Общие принципы ускорения WordPress, применимые в том числе поверх Redis, — в статье про скорость WordPress.

Настройка лимита памяти и вытеснения ключей

Без ограничения памяти Redis может занять всю доступную RAM на сервере. Задайте лимит и политику вытеснения явно:

# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru

Политика allkeys-lru вытесняет наименее недавно использованные ключи при достижении лимита — это безопасный выбор для объектного кэша WordPress. После изменения конфигурации перезапустите службу:

sudo systemctl restart redis-server

Для диагностики медленных запросов, которые Redis не решает сам по себе, — статья про slow query log в MySQL.

Как убедиться, что Redis реально снижает нагрузку

Hit rate в redis-cli info stats выше 90% после нескольких часов работы под обычной нагрузкой
Число SQL-запросов на страницу в Query Monitor заметно упало по сравнению с замером без Redis
used_memory остаётся в пределах заданного maxmemory без постоянного роста evicted_keys
TTFB стабильно ниже 150 мс на нескольких прогонах подряд, а не только на первом

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
redis-cli info memory | grep used_memory_human
redis-cli info clients | grep connected_clients