Если сайт на WordPress начал тормозить без видимой причины, очень часто проблема не в «тяжёлом хостинге», а в одном-двух медленных запросах к базе. Типичный сценарий: главная открывается нормально, но отдельные страницы, архивы или админка начинают заметно подвисать после установки плагина, смены темы или добавления нового блока в шаблон.
Для такой диагностики удобнее всего использовать Query Monitor: он показывает SQL-запросы, хуки, HTTP-запросы, ошибки PHP и источник вызова. Это не средство «ускорить сайт одной кнопкой», а инструмент, который помогает понять, что именно тормозит и где это исправлять.
Когда стоит искать именно медленные запросы
Сначала имеет смысл отличить проблему базы от других узких мест. Если долго отвечает только фронтенд, а в панели всё быстро, виноваты могут быть внешние API, тяжёлые изображения или скрипты. Если же медленно открываются и фронтенд, и /wp-admin/, а нагрузка на CPU растёт при каждом запросе, стоит смотреть SQL и количество обращений к базе.
Типичные признаки
- страницы открываются с разной скоростью без изменений в контенте;
- после установки плагина выросло время генерации страниц;
- в админке долго грузятся списки записей, таксономии или настройки;
- на одном и том же шаблоне заметно больше запросов, чем на других страницах;
- в логах хостинга появляются медленные запросы к
wp_postmeta,wp_optionsили большим таблицам плагинов.
Диагностика в Query Monitor: что смотреть в первую очередь
После установки плагина откройте проблемную страницу под учётной записью администратора. В верхней админ-панели появится меню Query Monitor. Для начала не нужно смотреть всё подряд: полезнее пройтись по нескольким конкретным разделам.
SQL Queries
Здесь видны все запросы, их количество и время выполнения. Ищите запросы, которые повторяются много раз, и те, что заметно выбиваются по времени. Важен не только сам SQL, но и компонент-источник: тема, конкретный плагин или ядро WordPress.
Hooks & Actions
Если запросов много, но непонятно, кто их запускает, полезно посмотреть цепочку хуков. Иногда медленная выборка появляется не в шаблоне напрямую, а внутри фильтра, который срабатывает десятки раз на одной странице.
Templates
Этот раздел помогает понять, какой шаблон отрабатывает на проблемной странице. Если медленный запрос связан с конкретным шаблоном архива или карточки записи, проще локализовать проблему в теме, а не искать её по всему сайту.
HTTP API Calls
Если страница тормозит из-за внешнего запроса, Query Monitor покажет это отдельно. Это важно: иногда «медленная база» на деле оказывается ожиданием ответа от стороннего сервиса, который вызывается в шаблоне или плагине.
Пошаговое решение: как локализовать источник
Ниже рабочая последовательность, которая обычно быстрее всего приводит к причине проблемы.
- Откройте проблемную страницу в браузере под админом.
- Посмотрите общее число SQL-запросов и суммарное время.
- Найдите самый медленный запрос и проверьте, какой компонент его сформировал.
- Сравните поведение на другой странице того же типа: если запрос повторяется, проблема системная; если нет — она привязана к конкретному шаблону или контенту.
- Отключите подозрительный плагин или временно переключите тему на стандартную, чтобы проверить, исчезает ли запрос.
- Если источник в теме, ищите запрос в
functions.php, шаблонахarchive.php,single.php,page.phpили в подключённых файлах.
Как проверить, что виноват именно плагин
Самый надёжный способ — временно деактивировать плагин на staging-копии и повторить замер. Если запрос исчез, значит, править нужно либо настройки плагина, либо его использование в шаблоне. Если запрос остаётся, источник, скорее всего, в теме или в другом плагине, который зависит от того же хука.
Пример: тяжёлый запрос к postmeta и как его упростить
Частая ситуация — поиск записей по метаполю через meta_query. Сам по себе WP_Query здесь не ошибка, но при больших объёмах данных он легко превращается в узкое место. Например, если на главной или в архиве вы фильтруете записи по нескольким метаполям, Query Monitor покажет длинный запрос с JOIN по wp_postmeta.
$args = array(
'post_type' => 'post',
'posts_per_page' => 12,
'meta_query' => array(
array(
'key' => 'featured',
'value' => '1',
'compare' => '=',
),
),
);
$query = new WP_Query( $args );Если такой фильтр нужен только для нескольких материалов, лучше не строить на нём весь архив. Практичнее хранить признак в таксономии или заранее подготовленном поле, которое не требует тяжёлой выборки на каждой странице. В отдельных случаях помогает и кэширование результата.
Когда уместен transient
Если список меняется не каждую минуту, можно закэшировать результат запроса через set_transient(). Это не лечит плохую структуру данных, но резко снижает количество повторных обращений к базе на часто открываемых страницах.
$cache_key = 'featured_posts_home';
$posts = get_transient( $cache_key );
if ( false === $posts ) {
$posts = get_posts( array(
'post_type' => 'post',
'posts_per_page' => 12,
'meta_key' => 'featured',
'meta_value' => '1',
) );
set_transient( $cache_key, $posts, HOUR_IN_SECONDS );
}После внедрения такого кэша обязательно проверьте, что данные обновляются там, где это нужно. Если список должен меняться сразу после редактирования записи, добавьте очистку transient при сохранении контента.
Сравнение подходов: плагин, код или кэш
| Подход | Когда подходит | Ограничение |
|---|---|---|
| Query Monitor | Для поиска причины медленного запроса | Не ускоряет сайт сам по себе |
| Правка темы/плагина | Если источник найден и запрос можно упростить | Нужны доступ к коду и тестовая копия |
| Transient / object cache | Если результат можно переиспользовать | Нужно следить за актуальностью данных |
Проверка результата после правки
После изменения кода не ограничивайтесь субъективным «стало быстрее». Сравните конкретные показатели на той же странице и в том же окружении.
- количество SQL-запросов до и после;
- суммарное время запросов в Query Monitor;
- исчез ли конкретный медленный запрос из списка;
- не сломались ли фильтры, сортировка и вывод контента;
- не выросло ли число запросов в другом месте после оптимизации.
Если у вас включён серверный кэш или плагин кэширования, очищайте его перед повторным тестом. Иначе можно получить ложное ощущение, что проблема ушла, хотя вы просто смотрите на закэшированную страницу.
Частые ошибки и как их исправить
Смотрят только на общее время загрузки
Общее время страницы мало помогает, если не видно, какой именно запрос тормозит. В Query Monitor нужно искать не «медленно вообще», а конкретный SQL, компонент и место вызова.
Оптимизируют запрос, не проверив источник
Иногда разработчик правит SQL вручную, но через день плагин снова генерирует тот же тяжёлый запрос. Сначала находите точку вызова, потом меняйте код.
Кэшируют всё подряд
Если закэшировать динамический список без логики сброса, пользователи будут видеть устаревшие данные. Для новостей, комментариев и часто обновляемых блоков это особенно заметно.
Тестируют только на продакшене
Query Monitor безопасен для диагностики, но любые правки кода лучше проверять на staging-копии. На живом сайте легко сломать вывод архива или скрыть проблему за кэшем.
Что ещё проверить, если запросы не исчезли
Если после правок медленный запрос всё ещё остаётся, проверьте соседние узкие места: автозагрузку в wp_options, тяжёлые виджеты, блоки с внешними запросами и плагины, которые добавляют свои таблицы. Иногда проблема не в одном запросе, а в их суммарном количестве.
Для регулярной технической чистки сайта полезно держать под рукой инструменты, которые помогают убирать лишнее и не тащить в продакшен мусорные настройки. Если нужен именно набор для SEO- и техоптимизации, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но саму причину медленных запросов всё равно лучше искать через диагностику, а не через «ускоряющие» переключатели.
В итоге рабочая схема всегда одна: сначала находите конкретный запрос и его источник, потом упрощаете код или кэшируете результат, и только после этого проверяете сайт на той же странице и в том же сценарии. Без этой последовательности легко потратить время на оптимизацию не того места.