Тормозит админка WordPress: что проверить первым

Сайт для посетителей открывается за 2 секунды, а wp-admin — 25–40. Список записей крутится, Elementor сохраняет страницу по минуте, в WooCommerce товар не публикуется. В практике это другая задача, чем «медленный фронт»: админка грузит все плагины сразу, шлёт Heartbeat и тянет лицензии с внешних API. Ниже — семь причин и порядок проверки за 1–2 часа без переустановки WordPress.

Почему админка тормозит, а сайт — нет

На фронте работает кэш: отдаётся готовая HTML-страница, часть плагинов не подключается. В wp-admin кэша нет — WordPress поднимает ядро, все активные плагины, тему, переводы, скрипты редактора. Плюс фоновые процессы:

• Heartbeat API — опрос сервера каждые 15–60 сек (автосохранение, блокировка записей).
• admin-ajax.php — виджеты дашборда, уведомления плагинов, проверка обновлений.
• Внешние запросы — лицензии премиум-плагинов, новости в дашборде, облачные сканы безопасности.

Если после обновления плагина админка «умерла» — сначала откат по FTP, потом диагностика ниже. Если тормозит годами — чаще накопленный хлам в БД и дубли расширений.

Причина 1. Лишние плагины в админке

Каждый активный плагин регистрирует хуки на admin_init, admin_enqueue_scripts, добавляет пункты меню и иногда SQL на каждой странице админки. Два SEO, два кэша, три «безопасности» — админка превращается в свалку.

Что сделать:

1. Установите Health Check & Troubleshooting (официальный) → режим troubleshooting: все плагины отключены, кроме выбранных. Если админка ожила — виновник среди плагинов.
2. Или по FTP переименуйте wp-content/plugins в plugins_OFF, включайте по одному.
3. Удалите неактивные плагины — они всё равно участвуют в проверке обновлений.

Ориентиры по количеству — в статье «Сколько плагинов WordPress нужно». На типовом корпоративном сайте после чистки до 12–15 активных админка часто ускоряется в 2–3 раза.

Причина 2. Heartbeat и автосохранение

Heartbeat держит сессию и автосохранение в редакторе. На страницах, где редактирования нет (список записей, настройки, список заказов WooCommerce), частый опрос грузит сервер.

Решение — плагин Heartbeat Control (бесплатный) или сниппет в functions.php дочерней темы:

• На дашборде и списках — интервал 60–120 сек или отключить.
• В редакторе постов/страниц — оставить 15–30 сек (автосохранение важно).
• На фронте — отключить, если тема/плагин не требует (корзина WooCommerce может требовать — проверить после отключения).

Не отключайте Heartbeat полностью в Gutenberg/Elementor без теста — можно потерять автосохранение и получить конфликт «запись уже редактируется».

Причина 3. Внешние API и виджеты дашборда

При входе в админку плагины и ядро запрашивают:

• api.wordpress.org — список обновлений;
• серверы лицензий (Elementor Pro, ACF Pro, WP Rocket и др.);
• облачные дашборды безопасности (Wordfence, Sucuri);
• новостные ленты в виджетах «События и новости».

На shared-хостинге с медленным исходящим каналом один «зависший» запрос к зарубежному API добавляет 5–15 сек к загрузке дашборда.

Что помогает:

• Свернуть или отключить лишние виджеты: «Настройки экрана» → снять галочки.
• В премиум-плагинах отключить «новости и советы» в настройках, если есть опция.
• На время диагностики — временно отключить плагины с облачным дашбордом.
• На VPS/выделенном — проверить DNS и firewall: не блокируется ли исходящий HTTPS.

Причина 4. Раздутая база: autoload и transients

WordPress при каждом запросе загружает в память все строки wp_options с autoload = yes. Плагины, которые «забыли» почистить настройки, раздувают autoload до 2–5 МБ — админка и фронт тормозят.

Проверка через phpMyAdmin или плагин WP-Optimize / Advanced Database Cleaner:

1. Размер autoload — ориентир < 800 КБ, тревога > 2 МБ.
2. Удалить просроченные _transient_* и _site_transient_*.
3. Очистить ревизии постов (оставить 3–5 последних) и спам-комментарии.

Перед чисткой БД — бэкап. Не удаляйте строки options вручную, если не знаете плагин-владелец — используйте плагины очистки с превью.

Причина 5. Конструктор и тяжёлые экраны редактирования

Elementor, WPBakery, Divi, Bricks грузят в админку десятки скриптов и стилей. На тарифе с 1 CPU и 256M RAM сохранение страницы на 50+ виджетах — 30–90 секунд. Это не «баг Elementor», а нехватка ресурсов + лишние аддоны.

Что проверить:

• В Elementor → Settings → Experiments включить оптимизации (DOM Output, Asset Loading) — см. ускорение фронта Elementor; часть настроек облегчает и редактор.
• Отключить неиспользуемые виджеты в Essential Addons, Crocoblock и аналогах.
• Поднять memory_limit до 512M для админки (wp-config или панель хостинга).
• На WooCommerce: экран «Заказы» с 10 000+ записей без лимита — пагинация и фильтр по дате; тяжёлые отчёты Analytics — отдельная тема, см. медленный WooCommerce.

Причина 6. Плагины безопасности и сканирование

Wordfence, iThemes Security, MalCare и аналоги при агрессивных настройках сканируют файлы при входе в админку или вешают live-traffic на каждый запрос. Админка «висит», пока идёт скан.

Рекомендации:

• Один плагин безопасности, не три. Сравнение подходов — в чек-листе защиты.
• Полное сканирование — по расписанию ночью (cron), не при каждом логине.
• Отключить «уведомления в реальном времени» в дашборде, если не нужны.

Причина 7. Хостинг и PHP под админку

Фронт отдаётся из кэша LiteSpeed — быстро. Админка бьёт в PHP и MySQL напрямую. Признаки упора в хостинг:

• TTFB любой страницы wp-admin > 3 сек в DevTools → Network;
• в панели Beget/Timeweb/Reg.ru — CPU 90%+ в момент сохранения записи;
• в логах — Allowed memory size exhausted или Maximum execution time.

Минимум: PHP 8.1+, memory_limit 256M (512M для Elementor + WooCommerce), OPcache включён. Если после чистки плагинов и БД админка всё ещё > 10 сек — смотреть тариф или VPS. Критерии — в статье про хостинг.

Диагностика за 30 минут: Query Monitor

Установите Query Monitor (только для админов, на проде не светите панель гостям). В верхней панели wp-admin смотрите:

• Queries — если > 200 SQL на одной странице админки, ищите плагин с N+1 запросами.
• Hooks — кто вешает тяжёлые callback на admin_init.
• HTTP API Calls — какой запрос к внешнему URL тормозит загрузку.
• Scripts — лишние JS на странице, которые можно отключить точечно.

После диагностики Query Monitor можно деактивировать — он сам добавляет нагрузку, если оставить навсегда.

Что НЕ нужно делать

• Не ставьте «ускоритель админки» поверх другого оптимизатора — чаще ломает редактор.
• Не отключайте все cron-задачи WordPress ради скорости — перестанут работать бэкапы и обновления.
• Не чистите wp_options вручную без бэкапа и понимания, что удаляете.
• Не путайте медленную админку с невозможностью войти — там другие причины (cookie, 403, security).
• Не переезжайте на другую CMS из-за тормозов админки — в 70% случаев хватает аудита плагинов и БД.

Когда позвать спеца

Если после чистки плагинов, Heartbeat и autoload админка всё ещё > 15 сек на списке записей или редактор падает по памяти — нужен аудит: профилирование SQL, настройка OPcache, перенос на тариф с большим CPU, точечная оптимизация WooCommerce/Elementor. Это уже не «галочки в настройках».

Разберём ваш случай и доведём админку до рабочего ритма — ускорение WordPress и техподдержка. Срочно «всё висит» после обновления — срочная починка.