WP-Optimize

WP-Optimize — плагин «два в одном»: чистка базы данных + кэширование страниц. Часто он уже стоит на сайте «для чистки», а про его страничный кэш никто не помнит. Именно так он достался мне на двух сайтах, и я прогнал его через полноценные замеры. Итог: кэш страниц у него отличный, но с двумя неочевидными ловушками.

Что умеет

• Чистка базы: ревизии, черновики, спам, транзиенты, логи — по расписанию или вручную.
• Кэш страниц для гостей: HTML-файлы на диске, отдача до загрузки WordPress.
• Минификация HTML/CSS/JS, откладывание JS, preload ссылок. (Управления Heartbeat у него нет — вопреки описанию в маркетплейсе; контроль heartbeat встроен в Breeze.)
• Сжатие изображений (частично платное), очистка кэша при публикации.

Подробный разбор чистки базы с замерами на трёх сайтах — в статье Чистка базы данных WordPress. Коротко: база не похудела и сайты не ускорились, но это нормальный результат — чистка гигиена, а не ускорение.

Кэш страниц: замеры на живом сайте с nginx

Стенд: небольшой журнал (~1 500 постов, 13 активных плагинов), VPS с nginx + PHP-FPM 8.5. Нагрузка ab -n 200 -c 10, замер с сервера.

Режим	Запросов/сек	TTFB (5 замеров)
Без кэша страниц	4,8	0,30–0,37 с
WP-Optimize кэш	174,2	15–19 мс
Breeze (для сравнения)	164,7	17 мс

Кэш WP-Optimize даёт ~36-кратный прирост RPS и ~20-кратное снижение TTFB. При этом посетитель маленького сайта разницы не заметит: 0,34 с без кэша — и так «мгновенно». Кэш здесь нужен ради запаса прочности под нагрузкой (4,8 → 174 запросов/сек), а не ради UX.

Ловушка №1: dropin самовосстанавливается

«Отключить кэш» удалением файла не получится: wp-content/advanced-cache.php WP-Optimize пересоздаёт при первом же запросе, если плагин активен. «Отключённый» кэш продолжает работать, и любой замер «до/после» будет врать.

Правильное отключение — штатный метод плагина:

wp eval "WP_Optimize()->get_page_cache()->disable();" --allow-root --path=/путь/к/сайту

И симметрично включение — ...->enable();. Важно: вызывать без --skip-plugins, иначе класс плагина не загрузится (а попытка всё равно уронит сайт в критическую ошибку).

Ловушка №2: http-домен в regenerated dropin

Если dropin генерируется из wp-cli (например, после disable → enable в консоли), в него записывается home_url() без https — в CLI нет HTTPS-контекста. А в dropin есть точная проверка раздачи главной страницы:

if (strcasecmp('http://домен.рф/', $protocol . '://' . $host . $request_uri) === 0) { … }

Все реальные посетители приходят по https → сравнение никогда не совпадает → кэш главной мёртв для всех, хотя файлы кэша исправно создаются и всё выглядит работающим. Симптом: «кэш включён, а скорость как без него». Лечение — поправить http→https в строке сравнения (или генерировать dropin из браузерного контекста).

Проверить, что кэш реально отдаётся, проще всего по времени ответа: тёплый запрос должен быть на порядок быстрее «холодного» рендера.

Когда WP-Optimize бесполезен

Та же история, что с Breeze и Varnish: если на сайте стоит обязательный экран согласия (18+), объявляющий DONOTCACHEPAGE, WP-Optimize честно не кэширует ни одной страницы. Проверено замером: каталог кэша пуст, каждый просмотр — полный рендер. В отличие от WP Fastest Cache, который этот заголовок игнорирует и ломает экран согласия закэшированной версией.

И ещё нюанс масштаба: на лёгком сайте (десяток плагинов, маленькая база, PHP 8.5 + OPcache) рендер живьём занимает ~16 мс — кэш страниц не меняет вообще ничего, что бы ни гласили инструкции. Сначала нагрузочный тест, потом плагин.

Выводы

• Кэш страниц WP-Optimize работает честно: 4,8 → 174 запросов/сек на лёгком сайте.
• Если плагин уже стоит «для чистки базы» — включите и кэш, это бесплатно.
• Не совмещайте с другим кэш-плагином: оба претендуют на advanced-cache.php.
• Отключение/включение — только штатными методами, иначе ловушки №1 и №2.
• На моём сайте в итоге остался WP-Optimize (кэш страниц + чистка в одном флаконе), а конкуренты проверены и отклонены — подробности в обзоре кеширования.