Если админка WordPress стала заметно медленнее, а страницы в панели открываются с задержкой, проблема часто не в одном «тяжёлом» плагине, а в наборе мелких запросов к базе данных. Типичный сценарий: на фронтенде всё терпимо, а в /wp-admin/ тормозит список записей, редактор, медиатека или даже главная страница панели.
В таких случаях полезно не гадать, а сначала понять, какие именно запросы повторяются, кто их инициирует и можно ли убрать их без потери функциональности. Ниже — рабочая схема, которая помогает локализовать источник нагрузки и снизить число лишних обращений к MySQL без опасных правок ядра.
Когда проблема действительно в запросах к базе
Не всякая медленная админка связана с SQL. Иногда виноваты внешний API, медленный хостинг, автозагрузка опций или кривой плагин, который на каждом экране делает один и тот же запрос. Поэтому сначала стоит отделить симптомы.
Признаки, что стоит смотреть именно в запросы
- админка тормозит на всех страницах, а не только в одном разделе;
- после отключения части плагинов интерфейс заметно оживает;
- в Query Monitor видно много одинаковых запросов;
- задержка растёт при большом числе записей, таксономий или метаполей;
- на хостинге нет явных ошибок, но CPU и MySQL нагружаются сильнее обычного.
Если у вас есть доступ к логам или профилировщику, полезно проверить не только количество запросов, но и повторяющиеся шаблоны: SELECT option_name, запросы к postmeta, term_relationships, wp_users и wp_usermeta. Именно они чаще всего всплывают в админке.
Диагностика: где искать источник лишних запросов
Самый удобный способ — поставить Query Monitor и открыть проблемную страницу в админке. Плагин покажет список SQL-запросов, их время, стек вызовов и компонент, который их инициировал. Это не «магия оптимизации», а просто способ увидеть, кто именно дергает базу.
Что смотреть в первую очередь
- одинаковые запросы, повторяющиеся десятки раз;
- запросы без индексов или с большим числом строк в результате;
- запросы, которые запускаются на каждом экране, хотя нужны только в одном разделе;
- мета-запросы с
meta_query, особенно по большим таблицам; - нагрузку от виджетов, блоков в редакторе и плагинов статистики.
Если Query Monitor показывает, что один и тот же плагин делает запросы на каждой загрузке админки, это уже повод проверить его настройки. Часто проблема не в самом плагине, а в том, что он собирает данные слишком агрессивно: статистику, внешние фиды, списки объектов, уведомления.
Пошаговое решение: как уменьшить число запросов
Ниже не универсальный рецепт, а последовательность действий. Идти лучше сверху вниз: сначала убрать очевидные источники, потом уже лезть в код.
1. Отключите то, что не нужно в админке
Многие плагины добавляют свои блоки, метабоксы, уведомления и запросы даже там, где они не нужны. Если какой-то функционал используется редко, его лучше отключить на уровне настроек или через фильтры плагина. Это особенно актуально для SEO-модулей, статистики, виджетов и конструкторов.
Если вы используете наборы оптимизационных настроек вроде Clearfy Pro, проверьте, не включены ли лишние элементы в head, дублирующиеся метаданные и ненужные сервисные функции. Но важно не «выключить всё подряд», а убрать только то, что реально не используется на проекте.
2. Уберите тяжёлые запросы из admin_init и общих хуков
Частая ошибка в кастомных плагинах и теме — запуск запросов на каждом экране админки через admin_init, init или даже безусловно при загрузке файла. Если данные нужны только на конкретной странице, ограничьте выполнение через get_current_screen() или проверку $hook_suffix.
<?php
add_action('current_screen', function ( $screen ) {
if ( ! $screen || 'post' !== $screen->base ) {
return;
}
// Выполняем запросы только на экране редактирования записи.
$recent_ids = get_posts([
'post_type' => 'post',
'posts_per_page' => 5,
'fields' => 'ids',
'no_found_rows' => true,
'update_post_meta_cache' => false,
'update_post_term_cache' => false,
]);
});Обратите внимание на параметры no_found_rows, update_post_meta_cache и update_post_term_cache. Они не всегда нужны, но в админке часто помогают сократить лишние обращения к базе, если вы просто получаете список ID.
3. Перепроверьте автозагрузку опций
Если в таблице wp_options слишком много автозагружаемых записей, WordPress тащит их почти на каждый запрос. Это не всегда видно сразу, но админка начинает «вязнуть» именно из-за этого. Проверять нужно не только количество, но и размер автозагрузки.
Для точечной диагностики можно посмотреть самые тяжёлые autoload-опции через SQL:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;Если наверху окажутся устаревшие кэши, временные данные или настройки удалённых плагинов, их стоит удалить после проверки, что они действительно не используются. Здесь важно не трогать системные опции вслепую.
4. Сократите мета-запросы в кастомном коде
Если в теме или плагине есть выборки по postmeta, проверьте, нельзя ли заменить их на таксономии, отдельную таблицу или хотя бы более узкий запрос. meta_query удобен, но на больших объёмах данных он быстро становится узким местом.
Плохой пример — искать записи по нескольким метаполям на каждом открытии списка в админке. Лучше заранее ограничить набор полей и не запрашивать лишние данные:
<?php
$args = [
'post_type' => 'post',
'posts_per_page' => 20,
'fields' => 'ids',
'no_found_rows' => true,
'update_post_meta_cache' => false,
'update_post_term_cache' => false,
'meta_query' => [
[
'key' => '_featured',
'value' => '1',
'compare' => '=',
],
],
];
$posts = get_posts( $args );Если такой запрос используется только для вывода счётчика или короткого списка, не загружайте полные объекты постов. Это банально, но на практике именно такие мелочи дают заметный эффект.
Сравнение подходов: плагин, код или компромисс
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин оптимизации | Нужно быстро убрать дубли, лишние метаданные, часть сервисных функций | Меньше ручной работы, проще откатить | Не решает кастомные запросы в теме и самописных плагинах |
| Код в теме/плагине | Проблема локализована в конкретном хуке или запросе | Точный контроль, можно убрать источник нагрузки | Нужна аккуратность и тестирование |
| Комбинированный вариант | Есть и мусорные опции, и тяжёлый кастомный код | Лучший баланс для реальных проектов | Требует дисциплины: сначала диагностика, потом правки |
Проверка результата после внедрения
Оптимизация имеет смысл только если вы можете показать, что стало лучше. Проверять нужно не «на глаз», а по тем же экранам, где была проблема.
Что сравнить до и после
- количество SQL-запросов на проблемной странице;
- время загрузки админки в Query Monitor;
- число повторяющихся запросов;
- нагрузку на MySQL в панели хостинга;
- скорость открытия списка записей, редактора и медиатеки.
Если вы убрали один источник запросов, но админка всё равно тормозит, значит есть ещё один слой проблемы: автозагрузка опций, тяжёлый редактор, внешний API или неудачная тема. Не останавливайтесь на первом найденном виновнике.
Частые ошибки и как их исправить
Отключили не то и сломали функциональность
Это типично для попыток «почистить всё подряд». Перед отключением модуля проверьте, где он используется: в редакторе, на фронтенде, в письмах, в REST API. Если сомневаетесь, сначала отключайте на staging-копии.
Оптимизировали запрос, но оставили его в общем хуке
Даже быстрый запрос, который выполняется на каждом экране, остаётся лишней нагрузкой. Если данные нужны только в одном месте, ограничьте выполнение по экрану или роли пользователя.
Удалили автозагрузку у системной опции
Не все опции можно переводить в autoload = no. Некоторые плагины ожидают, что данные будут доступны сразу. Если не уверены, сначала проверьте, кто читает эту опцию, и только потом меняйте поведение.
Смотрели только фронтенд
У многих проектов основная боль сидит именно в админке: редакторы, SEO-поля, списки записей, массовые действия. Если тестировать только главную страницу сайта, можно пропустить реальную проблему.
Чек-лист перед изменениями
- сделайте резервную копию базы данных;
- проверьте проблемный экран в Query Monitor;
- зафиксируйте количество запросов до изменений;
- отключайте плагины по одному, а не пачкой;
- не меняйте системные опции без понимания зависимости;
- тестируйте на staging, если проект рабочий;
- после правок повторите замер на том же экране.
Практические советы по безопасности и производительности
Если вы правите код вручную, не вносите изменения прямо в ядро темы или плагина. Для точечных оптимизаций лучше использовать дочернюю тему, mu-plugin или собственный мини-плагин. Так вы не потеряете правки после обновления.
Ещё один полезный момент: если на сайте много технического мусора — дублирующиеся метатеги, лишние сервисные блоки, неиспользуемые функции — сначала уберите его на уровне конфигурации, а уже потом переходите к коду. В проектах, где нужен более широкий набор чисток и SEO-оптимизаций, обычно удобнее держать это в одном инструменте, а не распылять по нескольким плагинам.
Если задача выходит за рамки одной правки и нужно системно почистить сайт от дублей, лишних элементов и части технического шума, имеет смысл посмотреть на Clearfy Pro. Но даже в этом случае сначала стоит понять, что именно тормозит сайт: плагин не заменяет диагностику.
В реальном проекте лучший результат обычно даёт связка из трёх вещей: убрать лишние автозагрузки, ограничить тяжёлые запросы по экрану и не запускать кастомный код без необходимости. Это скучно, но именно так админка WordPress перестаёт «проседать» без радикальной переделки сайта.