Админка WordPress тормозит: разгоняем панель управления

Админка тормозит по своим причинам, не тем, что фронт. Главные три: планировщик, который запускается на каждом обращении, обращения к внешним сервисам прямо во время загрузки страницы и раздутая автозагрузка настроек. У здоровой панели она держится в пределах 300-800 КБ.

Клиент пишет: «сайт у людей открывается нормально, а в админке работать невозможно». Открываешь список записей, спиннер крутится восемь секунд. Редактор задумывается после каждого второго абзаца, медиатека подгружает картинки с третьей попытки. Ускорение админки WordPress устроено иначе, чем ускорение публичной части: посетителю отдаётся готовая страница из кэша, а редактору каждый раз собирается живая динамика, и все накопленные за годы проблемы вылезают именно здесь. Ниже разбираю, где искать причину, в каком порядке и что из этого даёт реальный выигрыш по секундам.

Почему фронт летает, а панель ползёт

Кэш страниц, ради которого ставят LiteSpeed Cache или WP Super Cache, в админке не работает вообще. И правильно, что не работает: редактор должен видеть актуальные данные, а не снимок пятиминутной давности. Значит, каждый клик в wp-admin это полноценная генерация: подключаются все активные плагины, дёргается база, дописываются хуки, собираются списки.

Дальше добавляется вторая особенность. На фронте у типового сайта услуг живут пять-шесть шаблонов, и код половины плагинов туда просто не подключается. В админке подключается всё. SEO-плагин, конструктор форм, бэкапный плагин, аналитика, антиспам, магазинный модуль: каждый вешает свои экраны, метабоксы, колонки и фоновые проверки.

Третья причина самая обидная. Владелец платит за медленную админку деньгами, а не позициями. Контент-менеджер, который тратит по три минуты на публикацию новости вместо сорока секунд, за год сжигает несколько рабочих дней. У меня был клиент с турбазой, где администратор правила цены на шести страницах раз в неделю: после чистки эта операция сократилась с сорока минут до семи. Никакого волшебства, просто база перестала перечитывать мусор.

Сначала померить, потом чинить

Главная ошибка при разгоне админки: человек читает подборку советов и разом выключает Heartbeat, ревизии, автообновления и половину плагинов. Дальше что-то ломается, и непонятно, что именно помогло, а что навредило.

Порядок нормальный такой: замер, гипотеза, одно изменение, повторный замер.

Инструмент номер один это Query Monitor. Бесплатный, ставится в две минуты, показывает по каждой странице админки время генерации, число запросов к базе, самые медленные запросы, HTTP-вызовы наружу и разбивку по плагинам. Именно разбивка по плагинам решает большинство споров, потому что переводит разговор из «мне кажется, тормозит SEO-плагин» в «SEO-плагин съел 1,4 секунды из 3,1».

Ориентиры, на которые я опираюсь для сайта услуг на shared-хостинге:

Показатель	Хорошо	Терпимо	Пора чинить
Генерация страницы edit.php	до 0,6 с	до 1,5 с	больше 2,5 с
Число запросов к базе на экран	до 120	до 400	больше 800
Пиковая память PHP	до 64 МБ	до 128 МБ	упирается в лимит
Внешние HTTP-вызовы на экран	0	1-2	5 и больше
Размер автозагрузки wp_options	до 300 КБ	до 800 КБ	больше 1 МБ

Второй инструмент это вкладка Network в DevTools. Открываете список записей и смотрите, что именно долго: сам документ или запросы после загрузки. Если документ пришёл за 300 мс, а страница ощущается медленной, виноват фронтенд админки: тяжёлые скрипты плагинов, опросы admin-ajax.php, подгрузка миниатюр в медиатеке. Если документ тянется три секунды, копать надо на сервере. Подробный разбор того, как вычислять конкретный плагин-виновник, я разбирал в статье про то, какой плагин тормозит сайт: методика для фронта и для админки одна.

wp-cron на каждом запросе

Первый подозреваемый почти всегда один. WordPress по умолчанию не имеет своего планировщика: вместо него на каждом обращении к сайту проверяется, не пора ли выполнить отложенные задачи. Проверка запускает второй параллельный запрос к wp-cron.php, и если в очереди висит что-то тяжёлое (отправка писем, проверка обновлений, индексация SEO-плагином, синхронизация с внешним сервисом), то ждать будет тот, кто зашёл в этот момент. Чаще всего это вы, потому что на визитке с двадцатью посетителями в сутки именно администратор генерирует основную часть трафика.

Лечится в два действия. Отключаем встроенный псевдо-крон в wp-config.php:

// wp-config.php, выше строки "That's all, stop editing!"
define( 'DISABLE_WP_CRON', true );

И заводим системный крон, который дёргает тот же файл по расписанию. На большинстве российских хостингов задание добавляется через панель управления (у Timeweb и Beget это раздел «Планировщик задач»), реже через crontab -e на VPS:

*/5 * * * * curl -s https://example.ru/wp-cron.php?doing_wp_cron > /dev/null

Пять минут это разумный компромисс. Раз в минуту нужно только магазинам с отложенными статусами заказов, раз в пятнадцать минут достаточно сайту-визитке.

Проверить, что очередь не забита, можно через WP-CLI:

wp cron event list --fields=hook,next_run_relative,recurrence

Здесь ищем два симптома. Первый: события с датой в прошлом, они означают, что крон не выполняется вообще. Второй: десятки однотипных задач от одного плагина, обычно это следы кривой интеграции или брошенного импорта. Разовые зависшие задачи снимаются wp cron event delete <hook>.

Админка ходит в интернет за вас

Второй по частоте виновник это внешние HTTP-запросы, которые WordPress делает синхронно, прямо в процессе сборки страницы. Проверка обновлений ядра, тем и плагинов, валидация лицензионных ключей у платных плагинов, загрузка новостей на дашборд, отправка телеметрии.

Пока сторонние серверы отвечают быстро, вы этого не замечаете. Проблема в том, что часть сервисов после 2022 года отвечает из России со сбоями: запрос уходит, ответа нет, PHP честно ждёт таймаут. Пять секунд ожидания на каждый экран админки, и работать становится больно.

Диагноз ставится за минуту: в Query Monitor есть вкладка HTTP API Calls, там видно каждый вызов, домен и время ответа. Дальше решение зависит от находки.

• Плагин ломится к недоступному лицензионному серверу: либо ищем замену, либо режем домен на уровне сервера. Обратите внимание, что после блокировки такой плагин часто отключает часть функций.
• Тормозит дашборд с новостями WordPress: виджет «События и новости WordPress» убирается через «Настройки экрана» в правом верхнем углу.
• Виноват сам механизм проверки обновлений: его нельзя выключать совсем, это прямой путь к дырявому сайту. Правильнее перевести проверку на редкий график, оставив обновления безопасности.

Жёстко ограничить время ожидания можно небольшим mu-плагином. Кладём файл в wp-content/mu-plugins/limit-http.php:

<?php
// Не даём внешним запросам вешать админку дольше 3 секунд
add_filter( 'http_request_timeout', function ( $timeout ) {
    return is_admin() ? 3 : $timeout;
} );

Это не лечение, а обезболивающее. Но разница между тремя секундами и стандартными пятью на каждом экране заметна сразу.

Автозагрузка в wp_options

Таблица wp_options читается целиком при каждом запросе, но не вся: только строки с флагом autoload = yes. Задумано это под настройки сайта, размером в десятки килобайт. На практике плагины складывают туда кэши, логи, сериализованные массивы товаров и остатки от удалённых расширений, которые никто не подчистил.

Смотрим объём одним запросом:

SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb, COUNT(*) AS rows_cnt
FROM wp_options WHERE autoload = 'yes';

SELECT option_name, ROUND(LENGTH(option_value)/1024) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;

До 300 килобайт живём спокойно. Полтора мегабайта означают, что на каждый чих панель тащит из базы полтора мегабайта, распаковывает сериализованные структуры и держит их в памяти. У одного клиента с брошенным магазинным плагином автозагрузка была 11 МБ, время генерации любой страницы админки 4,5 секунды, и никакой кэш это не лечил.

Чистить руками через phpMyAdmin я не советую: легко снести нужное. Безопаснее снять флаг автозагрузки у конкретной жирной опции и посмотреть, что будет:

wp option get some_plugin_cache --format=json > /tmp/backup.json
wp db query "UPDATE wp_options SET autoload='no' WHERE option_name='some_plugin_cache';"

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

Ревизии, транзиенты и логи плагинов

Дальше идёт мусор в wp_posts и wp_postmeta. Ревизии записей WordPress хранит бесконечно: страница, которую редактировали двести раз, честно лежит в базе двумястами копиями. На фронте это почти не видно, а в админке список записей делает запросы с фильтрацией по типу, и таблица на 40 тысяч строк вместо 400 отвечает совсем по-другому.

Ограничиваем на будущее:

// wp-config.php
define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );

Убираем накопленное. Перед любой чисткой делаем дамп базы, это не ритуал, а страховка:

wp db export backup-before-cleanup.sql
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp transient delete --expired
wp db optimize

Транзиенты это временный кэш, который плагины кладут в ту же wp_options. По задумке они самоудаляются по сроку жизни, на практике просроченные записи копятся годами. Команда выше выносит только истёкшие, живой кэш не трогает.

Отдельная история это логи плагинов внутри базы: журналы форм, история отправленных писем, антиспам-статистика, таблицы аналитики. Каждая такая таблица растёт линейно и никем не чистится. Смотрим размеры и решаем по каждой:

SELECT table_name, ROUND(data_length/1024/1024) AS mb, table_rows
FROM information_schema.tables WHERE table_schema = DATABASE()
ORDER BY data_length DESC LIMIT 15;

Если сайту больше трёх лет и его никто системно не обслуживал, находки будут обязательно. Типовой набор таких находок и порядок разбора я описывал в материале про то, почему WordPress тормозит после трёх лет.

Тяжёлые списки записей и медиатека

Экран edit.php умеет быть медленным сам по себе. Каждый плагин норовит добавить туда свою колонку, а колонка это дополнительный запрос на каждую строку списка. Двадцать записей на экране, четыре лишние колонки, и вот вам восемьдесят лишних запросов.

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

• Убрать ненужные колонки через «Настройки экрана». Тот же выпадающий блок регулирует число записей на странице: поставьте 20 вместо 100 и сравните.
• Отключить подсчёт комментариев и SEO-баллов в списке, если плагин это позволяет.
• В медиатеке переключиться со списка плиток на табличный вид. Плиточный режим тянет миниатюры пачками, и на библиотеке в четыре тысячи файлов это заметно.
• Проверить, что миниатюры вообще сгенерированы. Если тема регистрирует восемь размеров, а картинки заливались до её установки, браузер тянет полноразмерные JPEG по 3 МБ.

Heartbeat и автосохранение

Heartbeat API это регулярные запросы браузера к admin-ajax.php: раз в 15 секунд в редакторе, раз в 60 на остальных экранах. Нужен он для блокировки записи от одновременного редактирования и уведомлений. На нормальном хостинге он не мешает, на перегруженном превращается в постоянную фоновую нагрузку, особенно когда у клиента открыто пять вкладок админки.

Полностью выключать не советую: потеряете предупреждение «запись редактирует другой пользователь». Разумнее увеличить интервал плагином Heartbeat Control до 60 секунд в редакторе и отключить на списках. Автосохранение растягиваем так:

define( 'AUTOSAVE_INTERVAL', 120 );

Когда виноват не WordPress, а хостинг

Бывает, что чистить нечего, а панель всё равно вялая. Тогда смотрим ниже уровнем.

Версия PHP. Разница между 7.4 и 8.2 на админке WordPress составляет 25-40 процентов по времени генерации, и это бесплатное ускорение. Порядок безопасного перехода я разбирал в статье про обновление PHP на хостинге.

OPcache. Проверяется через php -i | grep opcache.enable или страницу с phpinfo(). Если выключен, каждый запрос заново компилирует тысячи файлов ядра и плагинов. На shared-хостингах его иногда режут на дешёвых тарифах.

Лимиты тарифа. На большинстве российских shared-планов действует ограничение по CPU и числу одновременных PHP-процессов. Админка при этом попадает под общий лимит, и если фоновый бэкапный плагин выел квоту, ваши клики встают в очередь. В панели хостинга обычно есть график потребления CPU: посмотрите его в те часы, когда админка тормозит.

Лимит памяти. Экраны обновлений и импорта требуют больше остальных. Стандартные 40 МБ иногда мало:

define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Нормальный shared-хостинг для сайта услуг в 2026 году стоит в районе 350-700 рублей в месяц. Если ваш тариф дешевле и сайт живёт на нём третий год, апгрейд может оказаться дешевле любой оптимизации по часам.

Порядок работ и что это даёт

Так я разгоняю админку у клиентов. Цифры в последней колонке усреднённые по сайтам услуг на 200-800 страниц, разброс большой, но соотношение выигрышей держится стабильно.

Шаг	Время работы	Риск	Типовой выигрыш
Замер Query Monitor, снятие базовых цифр	20 мин	нет	0, но без него дальше вслепую
Перевод wp-cron на системный	15 мин	низкий	0,3-1,5 с на экран
Разбор внешних HTTP-запросов	30-60 мин	средний	до 5 с при недоступном сервисе
Чистка автозагрузки	30-90 мин	средний	0,2-2 с на экран
Ревизии, транзиенты, логи плагинов	30 мин	низкий при бэкапе	0,1-0,8 с
Колонки, Heartbeat, медиатека	20 мин	низкий	ощущается сильнее цифр
PHP 8.2, OPcache, лимиты	30-60 мин	средний	25-40 процентов

Суммарно это 3-5 часов работы. На типовой запущенной админке они превращают три-четыре секунды на экран в 0,6-0,9 секунды. Дальше начинается борьба за десятые доли, и она обычно уже не окупается.

Короткий чек-лист, который можно пройти самому за вечер:

• Поставить Query Monitor и записать время генерации edit.php до правок.
• Проверить wp cron event list на задачи с датой в прошлом.
• Посмотреть вкладку HTTP API Calls: есть ли вызовы дольше секунды.
• Посчитать объём автозагрузки в wp_options запросом выше.
• Выгрузить дамп базы перед любой чисткой.
• Удалить ревизии, истёкшие транзиенты, содержимое корзины.
• Убрать лишние колонки в списке записей и снизить число записей на экран.
• Проверить версию PHP и включённый OPcache.
• Повторить замер и сравнить с исходной цифрой.

С чего начать в вашем случае

Если админка стала медленной постепенно, начинайте с базы: автозагрузка, ревизии, логи плагинов. Если тормоза появились резко после установки или обновления плагина, идите сразу во внешние запросы и разбивку по плагинам в Query Monitor. Если медленно всё, включая фронт, проблема ниже уровнем, и оптимизация WordPress тут не поможет: смотрите тариф хостинга и версию PHP.

Чего делать точно не стоит: отключать проверку обновлений насовсем, сносить таблицы плагинов без бэкапа и ставить плагин-оптимизатор базы с обещанием ускорить всё в один клик. Последние обычно вычищают ревизии (полезно) и заодно чистят транзиенты живой корзины магазина (неприятно).

Разбор медленной админки с замерами и внятным отчётом занимает у меня 3-5 часов, входит в абонентское обслуживание и делается разово по тарифам. Если панель уже мешает работать и правки на сайт откладываются из-за неё, напишите через форму на главной: по паре скриншотов Query Monitor обычно понятно, где сидит основная секунда. Другие разборы производительности собраны в рубрике про скорость.

Частые вопросы

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

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

Что чинить в первую очередь

Отключить запуск планировщика на каждом обращении и перевести его на расписание сервера. Это самая частая причина, и правится она одной строкой в конфигурации.

Почему панель зависает на несколько секунд

Обычно она ждёт ответа от внешнего сервиса: проверка лицензии плагина, обновления, чужой API. Один недоступный сервис вешает загрузку страницы целиком.

Как найти виноватый плагин

Панелью отладки, которая показывает время запросов и их источник. Формулировка вида кажется, тормозит плагин превращается в конкретную цифру, и дальше уже понятно, что делать.