WordPress должен летать, а не медитировать

Васисуалий Пупкевич однажды прочитал, что Redis ускоряет WordPress. Нашёл плагин Redis Object Cache, установил, нажал «Включить» — и с видом человека, только что оптимизировавшего высоконагруженный сервис, пошёл пить кофе. Сайт, разумеется, не ускорился ни на миллисекунду. Потому что Redis — это не плагин, а отдельный сервис на сервере, который сначала нужно установить, настроить и подружить с PHP, и только потом подключать плагином. Поразмыслив, Васисуалий делегировал задачу Web-team Форсаж. Сайт взлетел. Кофе теперь пьётся заслуженно. Дальше — как повторить этот трюк своими руками, шаг за шагом.

Что такое Redis и зачем он WordPress

Redis (Remote Dictionary Server) — это молниеносное хранилище данных прямо в оперативной памяти сервера. Пока MySQL каждый раз честно лезет на диск за одними и теми же данными, Redis держит их в RAM и отдаёт быстрее, чем вы успеете моргнуть.

Для WordPress это даёт конкретные и измеримые плюсы:

• Меньше запросов к базе данных — повторяющиеся запросы отдаются из кеша, MySQL отдыхает
• Быстрее генерация страниц — PHP не пересчитывает то, что уже посчитано минуту назад
• Меньше нагрузка на сервер — особенно заметно при всплесках трафика
• Кеш переживает перезапуск PHP-FPM — в отличие от встроенного object cache WordPress, который живёт только в рамках одного запроса и забывает всё сразу после него

Как это работает в связке — наглядно видно на схеме: гости получают страницы через кеш, администраторы идят напрямую (чтобы не видеть устаревшую версию своих же правок), MySQL занимается только тем, чем действительно должен заниматься.

Шаг 1. Установка Redis

Обновляем пакеты и устанавливаем Redis:

sudo apt update
sudo apt install -y redis-server

Теперь настраиваем конфигурацию. Подключаемся через FTP-клиент под root, скачиваем файл /etc/redis/redis.conf и открываем в текстовом редакторе.

Находим и редактируем следующие строки (некоторые нужно раскомментировать, убрав #):

maxmemory 1gb
maxmemory-policy allkeys-lru
bind 127.0.0.1
requirepass ВАШ_СЛОЖНЫЙ_ПАРОЛЬ

Что означает каждая настройка:

maxmemory 1gb — жёсткий лимит памяти для Redis. Без него он может незаметно съесть всю доступную RAM и устроить на сервере несанкционированный банкет.

maxmemory-policy allkeys-lru — когда память заканчивается, Redis удаляет давно неиспользуемые ключи. Самая разумная стратегия для WordPress-кеша.

bind 127.0.0.1 — Redis слушает только локальные подключения. Снаружи — закрыт наглухо, и это правильно.

requirepass — пароль для подключения. Не «12345», не «password», не имя кота. Redis и так доступен только локально, но без пароля — это дверь без замка в квартире без сигнализации.

Сохраняем файл, загружаем обратно и перезапускаем Redis:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Проверяем, что Redis живой:

redis-cli -a ВАШ_СЛОЖНЫЙ_ПАРОЛЬ --no-auth-warning ping
redis-cli -a ВАШ_СЛОЖНЫЙ_ПАРОЛЬ --no-auth-warning info memory

Должны получить PONG и статистику по памяти. Если ввести команду без ключа -a — Redis молча проигнорирует запрос: пароль-то мы уже поставили, и он это всерьёз.

Шаг 2. PHP-расширение Redis

Redis установлен, но PHP о его существовании пока ничего не знает — они как соседи по подъезду, которые ни разу не здоровались.

Сначала уточните версию PHP, которая включена именно для вашего сайта — не в Hestia в целом, а конкретно для домена. Удобнее всего проверить через phpinfo.php — подробнее в нашем посте → Как проверить версию PHP через phpinfo.

Устанавливаем расширение для нужной версии (в примере — PHP 8.3):

sudo apt install -y php8.3-redis
sudo systemctl restart php8.3-fpm

Теперь соседи знакомы и общаются напрямую.

Шаг 3. Плагин Redis Object Cache

Устанавливаем плагин Redis Object Cache (автор — Tillman Tillet) через WP-CLI. Почему через WP-CLI, а не кликами в админке — объясняем в посте → Как запустить WordPress в режиме терминатора.

wp plugin install redis-cache --activate --path=/home/wphestia/web/ВАШ_САЙТ.РУ/public_html/ --allow-root

Добавляем настройки подключения в wp-config.php — перед строкой /* That's all, stop editing! */:

// Redis Object Cache
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'ВАШ_СЛОЖНЫЙ_ПАРОЛЬ' );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_MAXTTL', 86400 );
define( 'WP_REDIS_SELECTIVE_FLUSH', true );
define( 'WP_CACHE_KEY_SALT', 'ВАШСАЙТ_' );

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

Включаем кеш:

wp redis enable --path=/home/wphestia/web/ВАШ_САЙТ.РУ/public_html

Шаг 4. Двойное кеширование: Redis + WP Super Cache

Redis и WP Super Cache не конкурируют — они работают в паре и закрывают разные задачи:

• WP Super Cache кеширует готовые HTML-страницы и отдаёт их гостям без запуска PHP вообще
• Redis кеширует объекты PHP — запросы к базе данных, транзиенты, результаты вычислений

Вместе они образуют двойной щит: молниеносно для гостей, разумно для всего остального.

В настройках WP Super Cache переходим на вкладку Расширенные и выставляем параметры как на скриншотах:

Ключевые настройки:

• Метод доставки кеша: Эксперт — более эффективная доставка через прямые файлы
• Отключить кеширование для авторизованных пользователей — администраторы всегда видят живой сайт, а не вчерашнюю кешированную версию
• Не кешировать страницы с параметрами GET — защита от проблем с динамическими URL
• Сжимать файлы кеша — дополнительное ускорение отдачи
• Очистить все файлы кеша при публикации или обновлении — чтобы после сохранения поста посетители видели актуальную версию, а не призрак старой статьи

Правила в .htaccess: почему они работают на связке Nginx + Apache2

После сохранения настроек WP Super Cache автоматически записывает блок правил в .htaccess в корне сайта. Выглядит устрашающе:

# BEGIN WPSuperCache
# Директивы (строки) между `BEGIN WPSuperCache` и `END WPSuperCache`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]
</IfModule>
# END WPSuperCache

На первый взгляд — портянка, от которой хочется закрыть ноутбук и уйти жить в лес. Но логика простая: каждый блок проверяет набор условий, и если все совпали — отдаёт готовый кешированный файл напрямую, вообще не запуская PHP. Последовательно проверяются четыре варианта: сжатый HTTPS, сжатый HTTP, несжатый HTTPS, несжатый HTTP — на любой вкус браузера.

Ключевые условия в каждом блоке:

• Запрос не к файлу без слеша — только «чистые» URL
• Метод запроса не POST — формы кешу не интересны
• Пустая строка запроса — никаких GET-параметров
• Нет куки авторизации — залогиненые идят напрямую, минуя кеш
• Кешированный файл физически существует на диске

Почему это работает на связке Nginx + Apache2? В Hestia CP Nginx выступает как reverse proxy и принимает все входящие запросы первым. Статику (картинки, CSS, JS) Nginx отдаёт сам, не отвлекая Apache по пустякам. Динамические запросы проксирует в Apache, а тот уже честно читает .htaccess и применяет правила mod_rewrite. Так что снаружи всё выглядит как «Nginx-сервер», но директивы .htaccess от WP Super Cache прекрасно работают — их обрабатывает Apache во втором эшелоне обороны.

Если блок WPSuperCache в .htaccess после сохранения настроек не появился сам — зайдите на вкладку Простые и нажмите Обновить правила .htaccess вручную. Иногда плагин стесняется писать в файл без личного приглашения.

Финальная проверка

Подождите 1-2 минуты после настройки, затем проверяем, что кеш действительно наполняется:

# Сколько ключей накопилось
redis-cli -a 'ВАШ_СЛОЖНЫЙ_ПАРОЛЬ' dbsize

# Сколько памяти занято
redis-cli -a 'ВАШ_СЛОЖНЫЙ_ПАРОЛЬ' info memory | grep used_memory_human

# Живой мониторинг запросов (Ctrl+C для выхода)
redis-cli -a 'ВАШ_СЛОЖНЫЙ_ПАРОЛЬ' monitor

Проверка исключения администраторов. Зайдите на сайт под своей администраторской учёткой и выполните:

redis-cli -a 'ВАШ_СЛОЖНЫЙ_ПАРОЛЬ' monitor 2>/dev/null | grep -v "ВАШСАЙТ_"

При действиях залогиненого администратора новые ключи с пользовательскими данными создаваться не должны — плагин автоматически обходит кеш для авторизованных пользователей. Если создаются — что-то настроено не так, и самое время звать Web-team Форсаж, а не гадать на кофейной гуще.

Статистика в админке. Перейдите в wp-admin → Settings → Redis — там график соотношения попаданий и промахов кеша. После прогрева нормальный показатель: 60-90% hits. Меньше — либо кеш ещё не прогрелся, либо в настройках закралась ошибка.

Redis настроен, двойное кеширование работает, сайт летит. Васисуалий доволен, и, естественно, по-прежнему уверен, что в следующий раз справится сам.

redis-cli -a ВАШ_ПАРОЛЬ --no-auth-warning ping