Redis для WordPress: когда ускоряет сайт, а когда только добавляет проблем

Redis для WordPress: когда ускоряет сайт, а когда только добавляет проблем

Redis в WordPress чаще всего ставят как object cache: он снижает число повторных запросов к базе и помогает на сайтах с большим количеством одинаковых обращений. Особенно это заметно в админке, на WooCommerce и там, где много динамики: корзина, авторизация, поиск, фильтры.

Но Redis не лечит медленный код и кривые запросы. Если тема или плагин постоянно обращаются к базе без кеша на уровне приложения, Redis просто будет хранить лишнюю нагрузку. Перед внедрением проверьте:
— не упирается ли сайт в CPU, а не в БД;
— не сломан ли page cache;
— не дублируются ли плагины кеширования;
— достаточно ли памяти выделено под Redis.

Частая ошибка — включить Redis и забыть про инвалидцию кеша. Тогда после изменений в товарах, меню или настройках часть данных может жить в кеше дольше, чем нужно. Для WordPress важны корректные ключи, отдельный префикс для каждого сайта и контроль TTL, если он используется.

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

Ставьте Redis не “на всякий случай”, а после проверки узкого места: сначала база, потом кеш, потом метрики.