Как найти тяжелые запросы в WordPress и ускорить медленный сайт

Если WordPress-сайт стал заметно тормозить, а причина не очевидна, чаще всего проблема сидит не в одном месте, а в связке: тяжелый SQL-запрос, неудачная тема, плагин с лишними обращениями к базе или разросшаяся таблица в MySQL. В такой ситуации полезно не гадать, а быстро локализовать узкое место: сначала понять, какие запросы выполняются медленно, потом связать их с конкретным плагином или шаблоном, и только после этого что-то менять.

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

С чего начать, если сайт тормозит

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

Полезно сразу зафиксировать симптомы:

• долго открываются страницы даже без большого количества изображений;
• админка отвечает с задержкой;
• после отключения части плагинов сайт заметно оживает;
• нагрузка на CPU или MySQL растет в часы посещаемости;
• в логах или профилировщике видны повторяющиеся запросы к одним и тем же таблицам.

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

Как увидеть медленные запросы в WordPress

Самый практичный способ — включить отладку запросов на короткое время и посмотреть, что именно выполняется долго. Для этого в файле wp-config.php можно включить режим отладки WordPress. Делайте это только на время диагностики: на рабочем сайте не стоит оставлять подробный вывод ошибок и запросов надолго.

Минимальный набор для локальной проверки выглядит так:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После этого WordPress будет писать ошибки в файл wp-content/debug.log. Но сам по себе этот лог не показывает все медленные SQL-запросы. Для поиска именно тяжелых запросов удобнее использовать профилировщик или плагин, который умеет показывать запросы к базе и их источник.

На практике чаще всего используют один из двух подходов:

• Query Monitor — показывает SQL-запросы, время выполнения, вызовы PHP, HTTP-запросы и источник запроса;
• логирование на уровне MySQL — полезно, если есть доступ к серверу, но обычно это уже зона хостинга или администратора.

Для обычного сайта WordPress Query Monitor — самый быстрый путь. Он показывает не только сам запрос, но и то, какой плагин, тема или функция его вызвали. Это гораздо полезнее, чем просто видеть длинный список SQL.

Как найти источник тяжелого запроса

Когда вы открыли проблемную страницу с включенным профилированием, смотрите не только на время запроса, но и на его контекст. В Query Monitor важны три вещи: сам SQL, время выполнения и компонент-источник. Если запрос идет из конкретного плагина, это уже направление для проверки. Если источник — тема, значит, проблема может быть в шаблоне, цикле или дополнительном запросе внутри шаблона.

Типичные признаки:

• много одинаковых запросов — часто это N+1-проблема, когда код делает отдельный запрос для каждого элемента списка;
• запросы к wp_options — иногда виновата перегруженная автозагрузка опций или плагин, который хранит слишком много данных в options;
• запросы к метаданным — тяжелые выборки из wp_postmeta, wp_usermeta или wp_termmeta могут сильно замедлять сайт на больших объемах данных;
• запросы без индексов или с большим количеством JOIN — это уже вопрос структуры запроса и объема таблиц.

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

Что делать, если тормозит база данных

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

Проверять базу стоит в таком порядке:

1. посмотреть размер таблиц в phpMyAdmin или через панель хостинга;
2. проверить, нет ли очень больших таблиц wp_options, wp_postmeta, wp_actionscheduler_actions и похожих служебных таблиц плагинов;
3. оценить, не разрослась ли автозагрузка опций;
4. посмотреть, не создают ли плагины собственные тяжелые таблицы без индексов.

Особенно часто тормозит автозагрузка опций. WordPress загружает автозагружаемые настройки почти на каждый запрос, поэтому если плагин хранит там слишком много данных, сайт начинает медленнее отвечать даже на простых страницах. Это не всегда видно по внешним симптомам, но хорошо заметно в профилировщике и при анализе таблицы wp_options.

Если вы уверенно работаете с SQL и у вас есть резервная копия, можно посмотреть самые тяжелые автозагружаемые опции запросом к базе. Он не меняет данные, только показывает список:

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

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

Как отличить проблему темы от проблемы плагина

Если тяжелые запросы идут из шаблона, а не из плагина, проверка обычно сводится к изоляции. Самый безопасный способ — временно переключить тему на стандартную, например на одну из штатных тем WordPress, и посмотреть, исчезает ли торможение. Делать это лучше на тестовой копии сайта или в период минимального трафика, потому что переключение темы меняет внешний вид и может повлиять на верстку.

Если после смены темы сайт заметно ускорился, значит, проблема в шаблоне или в коде темы. Тогда ищите:

• лишние запросы в functions.php;
• запросы внутри циклов вывода постов;
• обращения к get_option() и get_post_meta() в каждом элементе списка;
• вызовы внешних API прямо при загрузке страницы.

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

Что обычно ускоряет сайт после поиска узкого места

Когда источник найден, решение зависит от того, что именно тормозит. Универсальной кнопки нет, но рабочие меры обычно такие:

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

Если проблема в повторяющихся запросах, иногда достаточно добавить кэширование результата в объектный кэш или хотя бы в transient. Но это имеет смысл только тогда, когда данные не меняются каждую секунду. Для часто обновляемого контента кэш нужно настраивать аккуратно, иначе вы получите устаревшие данные вместо ускорения.

Если сайт работает на обычном shared-хостинге, не стоит ожидать чудес от одной только оптимизации кода. Иногда узкое место — слабый MySQL, медленный диск или лимиты тарифа. В этом случае даже хороший запрос будет выполняться дольше, чем на более мощном сервере. Но сначала все равно стоит убрать очевидно лишние запросы: это дает самый предсказуемый эффект.

Как проверить, что стало быстрее

После изменений нужно сравнить не ощущения, а измеримые вещи. Откройте ту же страницу, которую вы использовали для диагностики, и проверьте:

• время генерации страницы в Query Monitor или другом профилировщике;
• количество SQL-запросов;
• самые медленные запросы и их источник;
• время ответа сервера в браузере и в панели хостинга, если она это показывает.

Если после правок количество запросов снизилось, а самые медленные запросы исчезли или стали короче, вы нашли правильное место. Если сайт все еще тормозит, но SQL уже выглядит нормально, ищите дальше: в PHP-коде, внешних HTTP-запросах, тяжелых изображениях, блокирующих скриптах или ограничениях хостинга. Но это уже другая ветка диагностики.

Хорошая практика — сохранять исходные наблюдения: какой запрос был самым медленным, из какого плагина или шаблона он пришел, что именно изменили. Тогда при следующем замедлении не придется начинать с нуля.

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

Главная идея простая: не пытайтесь ускорить WordPress вслепую. Сначала найдите конкретный медленный запрос, затем определите, кто его вызывает, и только после этого меняйте тему, плагин, структуру данных или настройки кэша. Такой порядок экономит время и не приводит к случайным поломкам.