WordPress тормозит: PHP, MySQL, wp-cron и autoload options — практичная диагностика

Когда жалуются на wordpress slow wp-admin, почти всегда видно одно и то же: админка «подвисает» на любых действиях (вход, список записей, редактор), а фронтенд при этом может быть терпимым. Причина обычно в «служебной» части WordPress: фоновые задачи (wp-cron), разросшиеся настройки, которые грузятся на каждом запросе (autoload options), и цепочка медленных запросов к базе (slow queries). На стороне PHP добавляются эффекты холодного старта без opcache, а на стороне приложения — отсутствие persistent object cache.

Ниже — практичный чек-лист: что измерять, где смотреть симптомы, и какие изменения дают максимальный прирост без рискованных «оптимизаторов».

Карта симптомов: как понять, куда копать

Перед настройками важно отличить типовые сценарии и не лечить «наугад»:

• Админка тормозит, фронтенд более-менее — часто виноваты wp-cron (особенно при низком трафике) и админские хуки плагинов.
• Тормозит всё, особенно первая загрузка после простоя — признаки проблем с PHP-воркерами и отсутствием/переполнением opcache.
• Пики нагрузки каждые N минут — планировщик задач (WP-Cron или системный cron), бэкапы, индексация, сканеры, импорты.
• Стабильно высокий TTFB — чаще всего база: slow queries, блокировки, неправильные индексы, тяжёлые запросы плагинов.

Если начать «крутить» PHP-FPM/NGINX без измерений, можно улучшить одну метрику и ухудшить другую. Поэтому сначала — минимальная диагностика и фиксация исходных цифр.

Быстрая диагностика без тяжёлых APM

1) Отделяем «медленно в PHP» от «медленно вокруг PHP»

Если есть доступ к логам, сравните время ответа и апстрим-время. На Nginx для этого удобно логировать $request_time и $upstream_response_time.

• Если $upstream_response_time близок к $request_time — основная задержка внутри PHP (и/или MySQL в рамках PHP-запроса).
• Если $upstream_response_time маленький, а $request_time большой — ищите проблемы в отдаче (буферизация, диск, сеть, лимиты), но для wp-admin это встречается реже.

2) Проверяем, не «убивает» ли wp-cron админку

wp-cron по умолчанию запускается не «по расписанию», а при заходах пользователей. На низком трафике задачи копятся и потом выполняются пачкой при первом визите в админку. На высоком трафике — наоборот, WP-Cron может стартовать слишком часто и создавать лишние параллельные обращения к PHP.

Типичный симптом: вы открываете wp-admin, и в это же время стартуют фоновые действия (обновления, рассылки, синхронизации, генерация миниатюр). Субъективно это ощущается как «ватная» админка.

3) Проверяем autoload options: «невидимая» нагрузка на каждый запрос

Часть настроек в wp_options помечена как autoload = 'yes' и загружается на каждом запросе одним крупным запросом. Если там оказываются мегабайты JSON/serialized-структур от плагинов, вы получаете лишнее чтение из MySQL, десериализацию в PHP и рост памяти на воркер.

4) Ищем slow queries и «тяжёлые» плагины

Slow queries в WordPress чаще всего означает либо упор в ресурсы/конфиг MySQL, либо запросы без индексов, которые генерируют плагины: фильтрации по meta_key/meta_value, LIKE по большим полям, сортировки и подсчёты по крупным таблицам.

В админке запросы обычно тяжелее фронтенда: фильтры, пагинация, сортировки, подсчёты, права доступа.

Если проект упирается в CPU/RAM/IO на общем окружении, перенос на VDS часто даёт самый быстрый эффект: можно изолировать ресурсы под PHP-FPM и MySQL и нормально включить кэши без компромиссов.

wp-cron: когда он делает хуже и как это чинить

Почему wp-cron вызывает тормоза

WP-Cron запускается через обращение к wp-cron.php и конкурирует за те же ресурсы, что и админка:

• занимает PHP-FPM воркеры, из-за чего растёт очередь;
• «догоняет» накопившиеся задачи одним заходом;
• иногда стартует параллельно (гонки) и умножает нагрузку.

Правильная схема: отключаем триггер и запускаем системным cron

Самая предсказуемая модель — отключить встроенный триггер WP-Cron и запускать задачи по расписанию системным cron. Тогда админка перестаёт быть «спусковым крючком».

1) В wp-config.php включите:

define('DISABLE_WP_CRON', true);

2) Добавьте cron-задачу на сервере (пример раз в минуту):

* * * * * php /var/www/site/public_html/wp-cron.php >/dev/null 2>&1

Путь к wp-cron.php и команда PHP зависят от окружения. Важно, чтобы это был CLI PHP, а не HTTP-запрос: меньше накладных расходов и проще контролировать среду выполнения.

Как понять, что cron всё ещё «роняет» производительность

Если после перевода на системный cron сайт стал ровнее, но периодически случаются провалы — измерьте длительность конкретных задач. Часто один плагин (бэкапы, импорт, рассылки, SEO-индексация) делает тяжёлую работу в cron и занимает воркеры/диск/базу.

Дальше варианты обычно такие: разнести задачи по времени, снизить частоту, ограничить параллелизм (если плагин умеет), вынести тяжёлое в отдельные воркеры/очереди.

Autoload options: как найти и уменьшить то, что грузится всегда

Диагностический запрос: кто занимает autoload

Подключитесь к базе и посмотрите самые «тяжёлые» опции среди автозагружаемых:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 30;

Если в топе видите опции на сотни килобайт или мегабайты — это почти гарантированный кандидат на оптимизацию.

Суммарный объём autoload

Оцените общий размер автозагружаемых данных:

SELECT SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload = 'yes';

Проблема не в количестве строк, а в суммарном объёме данных, которые грузятся всегда, даже если вы просто открыли «Записи» или «Плагины».

Что с этим делать безопасно

Правильный путь — точечно устранять источник «раздувания», а не «чистить всё подряд»:

• Обновить или заменить плагин, который хранит тяжёлые данные в autoload.
• Отключить автозагрузку для конкретной опции, если вы уверены, что она не нужна на каждом запросе.
• Удалить мусорные опции только после проверки, что код действительно не использует их.

Пример, как отключить autoload у конкретной опции:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'some_huge_plugin_option';

Перед изменениями в wp_options сделайте дамп базы и по возможности сначала проверьте на staging.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Slow queries: включаем сбор, читаем, лечим

Включаем slow log в MySQL/MariaDB

Лучший инструмент против ощущения «кажется, база тормозит» — slow query log. Включите логирование медленных запросов и задайте порог, чтобы ловить реальные проблемы (например, 0.5–1 секунда).

Обычно нужны параметры slow_query_log, slow_query_log_file, long_query_time (названия зависят от версии). После накопления данных посмотрите лидеров по суммарному времени и по частоте.

Частые причины медленных запросов в WordPress

• Запросы к wp_postmeta с фильтрацией по meta_value и сортировками.
• Тяжёлые выборки в админке для «табличных» плагинов (логи, заявки, статистика) без индексов.
• Поиск и фильтры, которые превращаются в LIKE '%...%' по большим полям.
• Разросшиеся таблицы плагинов без обслуживания и без корректной схемы индексов.

Быстрая точка контроля «прямо сейчас»

Для оперативной диагностики посмотрите длительные запросы и ожидания. Минимальный шаг — SHOW PROCESSLIST в моменты «подвисаний» и фиксация повторяющихся паттернов.

PHP: OPcache как базовая гигиена производительности

php opcache — не «ускоритель», а базовая часть продакшена. Без него PHP постоянно парсит и компилирует файлы в байткод, а WordPress — это тысячи файлов, особенно с плагинами.

Признаки проблем с OPcache

• После перезапуска быстро, потом снова деградация (кэш слишком мал и постоянно вытесняется).
• Высокая CPU-нагрузка при небольшом трафике.
• Сильно отличается время «первой» и последующих загрузок.

Проверьте opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, opcache.validate_timestamps. Для WordPress важно, чтобы кэш не был тесным: иначе вы платите накладными расходами на каждом запросе.

Если у вас частые деплои, не отключайте проверки таймстемпов без выстроенного процесса сброса OPcache. Иначе получите ситуацию «почему код не обновился».

Object cache: ускоряем повторяющиеся операции WordPress

Object cache кэширует результаты запросов и вычислений на уровне приложения. В WordPress он особенно полезен в админке, где много повторяющихся обращений к одним и тем же данным (права, таксономии, опции, мета).

Если вы планируете включать Redis или Memcached под object cache, смотрите практические нюансы настройки и типовые ошибки в статье Memcached и Redis для PHP: как выбрать и настроить кэш без сюрпризов.

Когда object cache даёт максимальный эффект

• На один запрос приходится много обращений к базе (даже если каждый запрос не очень медленный).
• Админкой активно пользуются несколько пользователей.
• Есть тяжёлые плагины (магазин, фильтры, кастомные типы, билдеры).

Важно различать object cache и page cache. Для wp-admin нужен именно object cache (page cache админку обычно не кэширует и это нормально).

Почему wp-admin может быть медленнее фронтенда

Это нормальная архитектурная реальность: админка — «комбайн» с кучей данных и хуков. Но ненормально, когда она становится непригодной.

Самые частые причины, которые реально дают секунды задержки:

• Плагины, которые добавляют метабоксы/виджеты и делают запросы на каждой странице админки.
• Автозагружаемые опции, которые раздулись и десериализуются постоянно.
• WP-Cron, который запускается «вместе» с вашим действием в админке.
• Отсутствие OPcache и object cache, из-за чего повторяющиеся операции стоят дорого.

Пошаговый план работ (минимум риска)

1. Зафиксируйте базовые метрики: время открытия типовых страниц wp-admin, CPU/RAM, количество запросов к БД, очередь PHP-FPM.
2. Переведите wp-cron на системный cron и проверьте, исчезли ли «случайные» подвисания.
3. Проверьте autoload options: найдите топ-30 по размеру, определите источник, уменьшите.
4. Включите сбор slow queries и найдите лидеров по суммарному времени и частоте.
5. Проверьте OPcache: достаточно ли памяти и лимита файлов, нет ли постоянного вытеснения.
6. Подключите object cache и сравните число запросов/время в админке до и после.

Типовые ошибки при «ускорении WordPress»

• Чистить базу «оптимизатором» без понимания: можно удалить нужные опции/транзиенты и получить нестабильность.
• Выключить wp-cron и забыть включить системный: письма, публикации по расписанию и фоновые задачи начнут «умирать».
• Лечить slow queries только увеличением ресурсов: иногда один индекс или настройка плагина решает больше, чем «добавим CPU».
• Смешивать разные кэши: page cache не решает проблемы wp-admin; OPcache не заменяет object cache.

Контрольный список: если «всё ещё медленно»

Если вы сделали базовые шаги, а wordpress slow wp-admin остался:

• Проверьте лимиты PHP-FPM: очередь, недостаток воркеров, память на процесс.
• Посмотрите блокировки в MySQL: долгие транзакции, конкуренция, ожидания на диске.
• Оцените дисковую подсистему: для базы и для PHP важнее латентность, чем «MB/s».
• Отключите подозрительные плагины на время (лучше на staging) и найдите виновника бинарным поиском.

В хорошей диагностике главное — повторяемость: меняем один фактор, сравниваем метрики, фиксируем результат. Тогда ускорение WordPress превращается из «магии» в инженерный процесс.

Если сайт вырос из типового виртуального окружения (много админки, импорты, тяжёлые плагины, активный редактор), часто проще и стабильнее вынести проект на VDS, чтобы контролировать ресурсы PHP/MySQL и кэши без компромиссов общего хостинга.