Query Monitor в WordPress: как найти медленные запросы и ошибки

Когда WordPress открывается медленно, первое желание — поставить ещё один кэширующий плагин. Иногда это помогает скрыть симптом, но не объясняет причину. На конкретной странице может выполняться сотня одинаковых SQL-запросов, один плагин может обращаться к базе в цикле, тема — генерировать PHP-warning, а REST-запрос — тратить несколько секунд на внешний API.

Query Monitor полезен именно как диагностический инструмент. Он показывает информацию для конкретной загрузки страницы и связывает многие проблемы с ответственным компонентом: плагином, темой, ядром WordPress или вызывающей функцией.

Что показывает Query Monitor

Официальная страница плагина на WordPress.org перечисляет основные группы данных: запросы к базе, включая медленные, дублирующиеся и ошибочные; PHP errors; шаблон и template hierarchy; rewrite rules; hooks/actions; HTTP API; REST API и другие данные окружения. Для SQL можно фильтровать запросы по типу, компоненту и вызывающей функции.

Источник: Query Monitor — WordPress.org.

Query Monitor — не ускоритель сайта

Плагин сам по себе не оптимизирует базу, не объединяет CSS и не настраивает Redis. Его задача — показать, что происходит внутри запроса. Поэтому правильный процесс выглядит так: воспроизвести медленный сценарий, собрать факты, определить компонент, исправить причину и повторить измерение.

Если после установки просто увидеть «200 queries» и удалить случайный плагин, диагностика теряет смысл. Важнее время каждого запроса, повторяемость, вызывающий код и контекст страницы.

Проводите диагностику на staging, когда это возможно

На production Query Monitor по умолчанию показывает данные только пользователям с соответствующими правами, но сам сбор расширенной диагностической информации всё равно лучше выполнять контролируемо. Для тяжёлого сайта или проблемы, требующей включения дополнительных debug-настроек, используйте staging.

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

Начните с одной конкретной медленной страницы

Не пытайтесь одновременно «оптимизировать весь WordPress». Выберите воспроизводимый URL: главную, категорию с фильтрами, карточку товара, wp-admin, checkout или REST endpoint. Зафиксируйте время ответа до изменений.

После загрузки страницы откройте меню Query Monitor в admin bar и посмотрите общий time, peak memory и запросы к базе. Затем переходите к деталям. Такой подход позволяет сравнивать одну и ту же операцию до и после исправления.

Ищите не количество SQL, а дорогие паттерны

Большое число SQL-запросов не всегда означает проблему. Десятки быстрых запросов из object cache могут быть менее заметны, чем один тяжёлый запрос с сортировкой по большому meta table.

В разделе Database Queries полезно смотреть:

• запросы с необычно большим временем выполнения;
• одинаковые запросы, повторённые много раз;
• ошибочные SQL;
• компонент, который инициировал запрос;
• call stack или вызывающую функцию.

Если один и тот же SELECT выполняется в цикле для каждого товара, проблема обычно архитектурная: данные нужно получить одним запросом, заранее собрать IDs или кэшировать результат.

Duplicate Queries часто указывают на N+1

Типичный пример: шаблон выводит 50 объектов и внутри каждого повторно запрашивает одно и то же дополнительное значение. На тестовом каталоге это незаметно, а на production с большой базой создаёт сотни обращений.

Query Monitor помогает увидеть повторяемость и вызывающий компонент. После этого уже можно решать, нужен ли prefetch, изменение WP_Query, отдельный кеш или исправление стороннего плагина.

Смотрите Queries by Component

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

Это не означает, что компонент с максимальным количеством запросов обязательно виноват. WooCommerce на checkout закономерно делает больше работы, чем простая статическая страница. Сравнивайте цифры с задачей страницы и ищите аномалии.

PHP Errors могут объяснить тормоза и нестабильность

Query Monitor выводит PHP warnings, notices, deprecated calls и связанные компоненты. Ошибка может не падать фатально, но постоянно записываться в лог, запускать лишний fallback или указывать на устаревший код после обновления PHP.

На production нельзя просто скрыть сообщения и считать проблему закрытой. Если предупреждение воспроизводится, найдите источник и исправьте его либо обновите компонент. Особенно важно проверить deprecated-функции перед сменой версии PHP или крупным обновлением WordPress.

Проверяйте HTTP API, если страница ждёт внешний сервис

Иногда база работает быстро, но backend ждёт CRM, API доставки, лицензирование плагина, валютный курс или другой внешний endpoint. Такие задержки не исправляются индексом MySQL.

В Query Monitor можно увидеть HTTP API calls и их контекст. Если внешний запрос выполняется синхронно на каждой загрузке страницы, подумайте о кешировании ответа, фоновой обработке или более коротком timeout.

REST API и AJAX нужно тестировать отдельно

Современный WordPress и WooCommerce активно используют REST API, Store API и AJAX. Страница в браузере может загрузиться быстро, а фильтр или checkout — зависать на отдельном запросе.

Воспроизводите именно проблемное действие и анализируйте соответствующий запрос. Query Monitor умеет добавлять диагностическую информацию к аутентифицированным REST API запросам для пользователей с нужными правами. Это помогает разбирать endpoint без догадок.

Не путайте admin-ajax.php с причиной проблемы

В DevTools часто видно медленный запрос к admin-ajax.php. Этот файл — только точка входа. Причиной может быть любой callback, зарегистрированный на конкретный action. Нужно определить обработчик и уже затем смотреть SQL, PHP и внешние вызовы.

Отдельный случай — Heartbeat API. Если нагрузку создаёт именно он, полезна отдельная настройка частоты и областей работы. Подробнее — в статье про Heartbeat API и admin-ajax.

Template и Hooks помогают найти лишнюю работу темы

Query Monitor показывает текущий template, hierarchy и связанные данные. Это полезно, если тяжёлый код запускается только на категории, поиске или конкретном custom post type.

Список hooks/actions позволяет понять, какие callbacks подключены к событию. Иногда дорогая функция висит на универсальном хуке и выполняется на каждой странице, хотя нужна только в админке или на checkout.

Проверяйте object cache и transient-логику

Медленный запрос, который нельзя убрать, часто можно не выполнять при каждом хите. Но кэш должен иметь понятную инвалидизацию. Бессрочное хранение динамических данных создаёт уже другую проблему — устаревшие остатки, цены или статусы.

Если проблема связана с большим объёмом autoloaded options, это отдельная область. Мы разбирали её в материале про autoloaded options и wp_options.

Как найти тормозящий плагин без хаотичного отключения

Без диагностики разработчик часто выключает плагины по одному и смотрит «стало ли быстрее». На staging такой метод допустим как контрольный тест, но Query Monitor позволяет сначала сузить круг.

1. Воспроизведите медленную страницу.
2. Посмотрите общий runtime и database time.
3. Откройте запросы по компонентам.
4. Найдите медленные/дублирующиеся запросы и PHP errors.
5. Если подозрение падает на конкретный плагин, только тогда отключите его на staging.
6. Повторите тот же URL и сравните метрики.

Так результат становится измеримым, а не субъективным.

Не оставляйте диагностические инструменты включёнными без необходимости

После исправления верните production в нормальный режим. Не держите расширенный debug output для посетителей, не публикуйте stack traces и не оставляйте тестовые endpoints. Query Monitor обычно ограничивает вывод администраторами, но права и окружение всё равно нужно проверить.

Также удалите временный код логирования и тестовые константы, если они были добавлены только для расследования.

Практический чек-лист диагностики

• зафиксировать конкретный URL и исходное время ответа;
• проверить database time и самые дорогие запросы;
• посмотреть duplicate queries;
• сгруппировать нагрузку по component;
• исправить PHP warnings/deprecated calls;
• проверить HTTP API calls;
• отдельно протестировать REST/AJAX;
• повторить замер после одного изменения;
• проверить production после deploy без debug-режима.

Итог

Query Monitor полезен тем, что превращает «WordPress тормозит» в конкретную техническую задачу: такой-то запрос повторяется 80 раз, такой-то плагин делает медленный внешний вызов, а такая-то функция темы генерирует PHP warning.

Если нужен технический аудит WordPress или WooCommerce по фактическим метрикам, можно прислать A.S Groups ссылку и описание симптома. Я сначала локализую причину, а затем предлагаю исправление — вместо установки набора оптимизаторов наугад.