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