Если WordPress стал тормозить, не спешите менять хостинг или отключать половину плагинов наугад. Часто проблема сидит в нескольких тяжелых SQL-запросах: они долго выполняются, нагружают базу данных и замедляют загрузку страниц даже на нормальном сервере. Задача здесь простая: сначала найти, какой именно запрос тормозит, потом понять, кто его запускает — плагин, тема или собственный код — и только после этого оптимизировать.
Ниже — рабочий порядок действий: как увидеть медленные запросы, чем их анализировать и что обычно дает самый заметный эффект.
С чего начать поиск медленных запросов
Сначала нужно понять, действительно ли узкое место в базе данных. Если страница долго открывается из-за тяжелых изображений, внешних скриптов или медленного сервера, SQL тут ни при чем. Но если в админке, на каталоге, в поиске или на отдельных страницах задержка повторяется стабильно, запросы к базе — один из первых подозреваемых.
Самый удобный путь — смотреть не на абстрактную «нагрузку», а на конкретные запросы и время их выполнения. Для этого обычно используют один из трех подходов:
- лог медленных запросов на стороне MySQL/MariaDB;
- профилирование внутри WordPress с помощью плагина или режима отладки;
- временное отключение плагинов и смена темы, чтобы локализовать источник.
Лучше не ограничиваться только одним способом. Например, лог базы покажет, что запрос медленный, но не всегда сразу объяснит, какой плагин его породил. А профилирование в WordPress помогает связать запрос с конкретным хуком, страницей или компонентом.
Как включить лог медленных запросов на сервере
Если у вас есть доступ к настройкам MySQL/MariaDB или к панели хостинга, это самый прямой способ. Лог медленных запросов фиксирует SQL-команды, которые выполняются дольше заданного порога. Обычно для диагностики ставят небольшой порог, например 1 секунду, но точное значение зависит от нагрузки и возможностей хостинга.
На выделенном сервере или VPS можно включить slow query log в конфигурации MySQL/MariaDB. На общем хостинге такой доступ часто закрыт, тогда остается панель хостинга или поддержка. Важно: не меняйте параметры базы, если не понимаете, как сделать откат. Неправильная настройка может повлиять на производительность всего сайта.
После включения лога откройте проблемную страницу несколько раз, выполните типичные действия в админке и посмотрите, какие запросы попали в журнал. Ищите не только длинные запросы, но и те, которые повторяются десятки раз за одну загрузку. Иногда один запрос сам по себе не очень долгий, но его массовый вызов делает страницу тяжелой.
Что смотреть в запросе, чтобы понять источник проблемы
Сам по себе SQL-текст еще не говорит, кто виноват. Но по нему часто можно быстро сузить круг поиска.
- Запросы к таблицам с префиксом
wp_posts,wp_postmeta,wp_options,wp_termsиwp_termmetaобычно связаны с типовой работой WordPress, плагинами или темой. - Если в запросе участвуют нестандартные таблицы, почти наверняка это плагин или кастомный код.
- Большое количество
JOIN,ORDER BY,LIKEи подзапросов часто указывает на тяжелую выборку, особенно если таблицы большие. - Если запрос идет к
wp_optionsбез явной причины, стоит проверить автозагрузку опций и плагины, которые активно пишут в настройки.
Полезно смотреть не только текст запроса, но и контекст: на какой странице он выполнялся, сколько раз повторился и сколько времени суммарно занял. Один и тот же SQL может быть безобидным на сайте с сотней записей и очень дорогим на сайте с десятками тысяч товаров, постов или метаполей.
Как найти плагин или тему, которые запускают тяжелые запросы
Если лог показал медленный SQL, следующий шаг — связать его с конкретным компонентом WordPress. Здесь помогает поочередная проверка.
Самый практичный способ — временно отключать плагины группами и проверять, исчезает ли проблема. Если сайт большой, не делайте это на живом проекте без подготовки: можно сломать формы, поиск, личный кабинет или интеграции. Лучше использовать staging-копию или хотя бы окно с минимальным трафиком.
Порядок обычно такой:
- отключите все плагины, кроме критически необходимых;
- проверьте скорость проблемной страницы;
- включайте плагины по одному или группами, пока задержка не вернется;
- после этого проверьте тему: временно переключитесь на стандартную тему WordPress, например Twenty Twenty-Four, и сравните результат.
Если проблема исчезает при отключении конкретного плагина, почти всегда виноват не WordPress как платформа, а логика этого плагина: тяжелый запрос, неудачный фильтр, лишняя выборка метаданных или слишком частые обращения к базе. С темой похожая история: иногда она делает слишком много запросов в шаблоне, особенно на архивных страницах, в шапке, сайдбаре или виджетах.
Профилирование внутри WordPress: когда нужен точный ответ
Если вы не хотите гадать, какой именно код запускает запрос, используйте профилирование. Для WordPress это особенно полезно, когда проблема не в одном очевидном SQL, а в цепочке вызовов: тема вызывает функцию, функция дергает плагин, а тот делает несколько запросов подряд.
Встроенный режим отладки WordPress помогает увидеть ошибки и часть служебной информации, но для анализа запросов удобнее инструменты профилирования и мониторинга запросов. Они показывают, сколько запросов выполнилось на странице, какие из них повторяются и какой код их инициировал.
Если используете плагин для профилирования, проверяйте именно три вещи:
- количество запросов на страницу;
- самые медленные запросы по времени;
- повторяющиеся запросы, которые можно объединить или закешировать.
Здесь важна аккуратность: профилирование само по себе добавляет нагрузку, поэтому измеряйте на тестовой копии или короткими сессиями. Не держите отладку включенной постоянно на боевом сайте.
Что оптимизировать в первую очередь
Когда источник найден, не пытайтесь сразу «ускорить все». Обычно быстрее всего дают эффект несколько типовых исправлений.
Сократить повторяющиеся запросы
Если один и тот же запрос выполняется много раз в рамках одной страницы, его часто можно закешировать на уровне кода, использовать уже загруженные данные или изменить логику шаблона. Это особенно актуально для тем, которые в цикле обращаются к метаполям, терминам или пользовательским данным.
Упростить тяжелые выборки
Запросы с большим количеством соединений и сортировок стоит пересмотреть. Иногда достаточно убрать лишний ORDER BY, ограничить выборку, не тянуть лишние поля или заменить поиск по метаполю на более подходящую структуру данных. Если запрос строит плагин, проверьте, нет ли у него настроек, которые уменьшают объем выборки.
Почистить автозагрузку и лишние опции
Если тормозит админка или каждая страница делает лишние обращения к wp_options, проверьте автозагружаемые опции. Слишком большой объем автозагрузки замедляет старт WordPress еще до рендера страницы. Но удалять опции вручную нужно осторожно: сначала выясните, какой плагин их создал, и убедитесь, что они не нужны.
Добавить или исправить индексы
Иногда запрос медленный не из-за логики, а из-за отсутствия подходящего индекса в таблице. Это уже уровень базы данных, и здесь нельзя действовать вслепую. Неправильный индекс может не помочь или даже ухудшить запись в таблицу. Если вы не уверены, сначала проверьте запрос на тестовой копии и только потом вносите изменения.
Когда проблема не в SQL, хотя кажется иначе
Бывает, что медленный запрос — не первопричина, а следствие. Например, сервер перегружен, PHP-обработчик занят, а запросы просто ждут своей очереди. Или страница тормозит из-за внешнего API, а база в это время работает нормально. Поэтому после первого анализа полезно проверить общую картину:
- время ответа сервера до начала генерации страницы;
- количество запросов на одной странице;
- нагрузку на CPU и память в момент тормозов;
- есть ли одинаковая задержка на всех страницах или только на отдельных шаблонах.
Если медленно только несколько страниц, ищите проблему в их шаблоне, блоках, виджетах или специфическом плагине. Если тормозит весь сайт, смотрите шире: база, кэш, сервер, тяжелые фоновые задачи WordPress и объем автозагрузки.
Как проверить, что сайт действительно стал быстрее
После изменений не ориентируйтесь на субъективное ощущение. Откройте ту же страницу, которая тормозила раньше, и сравните:
- время полной загрузки страницы;
- количество SQL-запросов;
- самые медленные запросы;
- поведение в админке и на фронтенде.
Если вы отключили плагин или изменили шаблон, проверьте не только скорость, но и функциональность. Иногда ускорение достигается ценой поломанной логики: исчезает фильтр, не работает поиск, ломается сортировка или перестают подгружаться нужные данные. Это особенно важно на сайтах с кастомными типами записей, каталогами и сложными шаблонами.
Хороший результат выглядит так: медленные запросы либо исчезли, либо стали реже и короче, а проблемная страница перестала выбиваться по времени загрузки на фоне остальных. Если этого не произошло, возвращайтесь к диагностике и смотрите следующий слой — плагин, тему, структуру таблиц или сервер.
Если вам нужно не только найти источник, но и убрать лишние служебные запросы WordPress, имеет смысл отдельно проверить чистоту базы и объем автозагрузки. Для этого иногда используют плагины оптимизации, но выбирать их стоит по конкретной задаче, а не как универсальное средство от всех тормозов.