Если страницы WordPress открываются заметно медленнее обычного, искать причину лучше не «на глаз», а по цепочке: сначала понять, где именно теряется время, затем найти конкретный медленный запрос, а уже после этого — плагин, тему или фрагмент кода, который его вызывает. В большинстве случаев тормозит не сам WordPress, а один из трёх слоёв: база данных, PHP-код темы или плагина, либо внешний запрос к API, который блокирует генерацию страницы.
Ниже — рабочий порядок диагностики, который помогает не гадать, а быстро сузить круг поиска.
С чего начать: определить, что именно тормозит
Сначала нужно понять, проблема в генерации страницы или в доставке. Если сервер долго формирует HTML, виноваты обычно PHP, база данных или внешний запрос. Если HTML уже готов, но страница долго загружается в браузере, причина может быть в тяжёлых скриптах, изображениях или сторонних сервисах. Для поиска медленных запросов нас интересует именно первый случай.
Самый простой ориентир — время ответа сервера и TTFB. Если TTFB высокий, страница долго собирается на сервере. Это уже повод искать медленные SQL-запросы, тяжёлые хуки и код в теме или плагинах.
Самый удобный способ: Query Monitor
Для живой диагностики в WordPress удобнее всего использовать плагин Query Monitor. Он показывает SQL-запросы, время их выполнения, источник вызова, PHP-ошибки, запросы к внешним сервисам и многое другое. Для практической проверки это один из самых полезных инструментов, потому что он сразу связывает медленный запрос с конкретным файлом темы или плагина.
Что делать:
- Установите и активируйте Query Monitor на тестовом или рабочем сайте, если вы понимаете риски.
- Откройте проблемную страницу, будучи авторизованным администратором.
- В верхней админ-панели откройте панель Query Monitor.
- Перейдите в раздел с запросами к базе данных.
Ищите запросы с заметно большим временем выполнения, а не просто с большим количеством повторов. Один запрос на 300–500 мс на каждом открытии страницы уже может быть проблемой, особенно если он выполняется несколько раз. Важно смотреть не только на сам SQL, но и на caller — откуда он был вызван. Query Monitor обычно показывает файл плагина, темы или ядра, который инициировал запрос.
Если вы видите одинаковый запрос много раз, это часто признак неэффективного цикла, лишнего обращения к метаданным постов, опций или таксономий. Если запрос один, но очень тяжёлый, проблема может быть в отсутствии индекса, слишком широком фильтре или в том, что код тянет слишком много данных из базы.
Как понять, какой плагин или тема запускает медленный запрос
Сам по себе SQL-запрос ещё не отвечает на главный вопрос владельца сайта: кто виноват. Для этого нужно смотреть на источник вызова. В Query Monitor обычно видно стек вызовов или хотя бы путь к файлу, который инициировал запрос. Это позволяет отличить запрос ядра WordPress от запроса, который пришёл из плагина, темы или кастомного кода.
Практически это выглядит так:
- если путь ведёт в папку плагина — сначала проверяйте именно его;
- если запрос идёт из темы — ищите шаблон, функцию в
functions.phpили подключённый файл; - если источник в ядре WordPress, часто проблема не в ядре, а в том, как тема или плагин используют стандартные функции.
Полезно смотреть на повторяющиеся паттерны. Например, если на каждой странице выполняется тяжёлый запрос к wp_postmeta, это часто связано с выводом произвольных полей, виджетов, блоков или фильтров, которые делают лишние обращения к базе. Если тормозит админка, причиной нередко оказываются плагины статистики, SEO, фильтров, импорта или синхронизации с внешними сервисами.
Проверка без лишнего риска: отключать по одному и сравнивать
Если источник неочевиден, самый надёжный способ — поочерёдно отключать плагины и временно переключать тему. Делать это лучше на staging-копии, а не на боевом сайте. На рабочем проекте такой тест может сломать формы, корзину, кастомные блоки или внешний вид страниц.
Порядок проверки обычно такой:
- Сначала отключите плагины, которые явно связаны с логикой страницы: фильтры, конструкторы, кеш, SEO, интеграции, импорт, статистика.
- После каждого отключения снова откройте проблемную страницу и сравните время ответа.
- Если разница появилась, значит виноват последний отключённый плагин или его взаимодействие с темой.
- Если плагины не помогли, временно переключите тему на стандартную, например Twenty Twenty-Four, и повторите проверку.
Такой подход медленнее, чем просмотр логов, но он хорошо работает, когда Query Monitor показывает только общий источник, а не конкретную причину. Главное — менять только один параметр за раз, иначе вы не поймёте, что именно повлияло на скорость.
Когда смотреть в логи MySQL и медленные запросы на сервере
Если сайт большой или проблема проявляется не всегда, полезно проверить серверный slow query log MySQL/MariaDB. Это уже уровень хостинга или VPS: WordPress сам по себе такой лог не ведёт. На некоторых хостингах доступ к нему есть через панель управления, на других — только через поддержку или SSH.
Этот способ особенно полезен, если:
- Query Monitor показывает медленные запросы, но не даёт полной картины;
- проблема возникает под нагрузкой, а не на одиночной странице;
- нужно понять, какие запросы реально «съедают» время на сервере, а не только в браузере администратора.
В логе ищут запросы с большим временем выполнения и повторяющиеся шаблоны. Если один и тот же запрос появляется часто, это уже кандидат на оптимизацию. Но здесь важно не делать выводы по одному событию: для оценки нужны повторяющиеся записи, иначе можно поймать случайный всплеск нагрузки.
Что делать с найденным узким местом
Когда вы нашли конкретный запрос, не спешите сразу переписывать всё подряд. Сначала нужно понять, почему он медленный. Причины обычно такие:
- слишком много данных выбирается из базы;
- запрос выполняется слишком часто;
- код делает одинаковую работу в цикле;
- плагин обращается к внешнему API на каждом открытии страницы;
- в базе нет подходящей структуры данных для такого типа выборки.
Если запрос идёт из плагина, сначала проверьте его настройки: иногда можно отключить лишний модуль, уменьшить объём данных, убрать лишний виджет или кэшировать результат. Если источник в теме, ищите шаблон, который выводит слишком много метаданных, связанных записей или блоков. Если это кастомный код, стоит проверить, не вызывается ли один и тот же запрос внутри while или в нескольких хуках подряд.
Для сложных случаев полезно добавить кэширование результата на уровне WordPress, но только если данные не должны обновляться мгновенно. Иначе можно получить быстрый, но устаревший вывод. Здесь важно не лечить симптом вслепую: если запрос медленный из-за плохой логики, кэш лишь отложит проблему, а не устранит её.
Как проверить, что проблема действительно решена
После исправления нужно повторить измерение тем же способом, которым вы нашли проблему. Иначе легко принять случайное улучшение за результат работы.
Проверьте три вещи:
- Время ответа страницы стало стабильнее, а не только быстрее один раз.
- В Query Monitor исчез или заметно ускорился конкретный запрос.
- Источник вызова больше не указывает на проблемный плагин, шаблон или участок кода.
Если вы оптимизировали запрос, но страница всё ещё медленная, ищите следующий узкий участок. На практике тормоза часто складываются из нескольких средних проблем, а не из одной катастрофической.
Что обычно мешает диагностике
Есть несколько типичных ошибок, из-за которых поиск затягивается. Во-первых, сравнивают страницы без одинаковых условий: кэш уже прогрет, пользователь авторизован, включён CDN или отличается мобильная версия. Во-вторых, отключают сразу много плагинов и теряют связь между причиной и эффектом. В-третьих, смотрят только на фронтенд, хотя медленный запрос может быть в админке, cron-задаче или AJAX-обработчике.
Если нужна точная диагностика, тестируйте одну и ту же страницу, в одном и том же состоянии, с одинаковым набором активных компонентов. Тогда медленный запрос будет видно гораздо быстрее, а выводы окажутся надёжнее.
Когда вы научитесь читать Query Monitor и сопоставлять его данные с кодом темы и плагинов, поиск узких мест перестаёт быть угадайкой. Вы видите не просто «сайт тормозит», а конкретный запрос, конкретный источник и понятный следующий шаг: отключить, переписать, закэшировать или вынести логику из горячего пути загрузки страницы.