Если WordPress начал заметно тормозить, а в админке всё открывается с задержкой, проблема часто не в «слабом сервере», а в лишних запросах к базе данных. Обычно сайт делает больше обращений к MySQL, чем ему действительно нужно: из-за тяжёлой темы, неудачных плагинов, лишних блоков на страницах, автозагрузки опций или постоянных запросов в цикле. Хорошая новость в том, что во многих случаях нагрузку можно снизить без переписывания сайта с нуля.
Сначала нужно понять, откуда именно берутся запросы. Потом убрать самые дорогие источники: повторяющиеся запросы в шаблонах, перегруженные плагины, лишние данные в базе и неудачную конфигурацию кэша. Ниже — практический порядок действий, который помогает на реальных проектах.
С чего начать: найти источник лишних запросов
Снижать нагрузку вслепую не стоит. Один и тот же симптом — медленная загрузка страницы — может быть вызван разными причинами: слишком большим числом запросов, медленными запросами, отсутствием объектного кэша или просто тяжёлым внешним API, которое заставляет WordPress каждый раз лезть в базу.
Для первичной диагностики удобно включить отладку запросов в тестовой среде или на короткое время на проблемном сайте. В wp-config.php можно временно добавить:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'SAVEQUERIES', true );Параметр SAVEQUERIES сохраняет список запросов и время их выполнения. Это полезно для локальной проверки, но не для постоянной работы на боевом сайте: он добавляет накладные расходы. После диагностики его нужно убрать или выключить.
Дальше смотрят не только на количество запросов, но и на повторяющиеся шаблоны. Если одна и та же таблица дергается десятки раз на одной странице, значит, проблема в теме, плагине или в том, как собран шаблон.
Уберите самые частые источники лишних запросов
На практике больше всего запросов создают не «сложные» места, а обычные шаблоны, которые написаны без учёта повторного использования данных. Вот что проверяют в первую очередь.
Повторные запросы в циклах и шаблонах
Типичная ошибка — вызывать функции, которые обращаются к базе, внутри цикла по записям или в нескольких местах одного шаблона. Например, если тема на каждой карточке поста отдельно запрашивает автора, метаданные, термины и дополнительные поля, число обращений растёт очень быстро.
Что делать:
- проверить, не вызываются ли одни и те же функции несколько раз подряд для одного и того же объекта;
- сохранять результат в переменную, если данные уже получены;
- не делать отдельный запрос там, где можно использовать уже загруженные данные объекта записи.
Если вы правите тему, ищите повторяющиеся вызовы get_post_meta(), get_the_terms(), get_userdata(), get_option() и похожих функций в шаблонах карточек, сайдбаров и блоков «похожие записи».
Лишние запросы из плагинов
Некоторые плагины добавляют запросы на каждой странице, даже если их функциональность нужна только на части сайта. Это особенно заметно у плагинов статистики, конструкторов, слайдеров, форм, фильтров и расширенных виджетов.
Здесь помогает не «удалить всё подряд», а проверить, где плагин реально нужен. Если модуль используется только на одной странице, а его код и запросы грузятся по всему сайту, лучше ограничить его подключение. Иногда достаточно отключить отдельную опцию внутри плагина, а иногда — заменить тяжёлый плагин на более лёгкий аналог.
Если у вас есть доступ к профилированию, сравните количество запросов до и после отключения подозрительного плагина. Это самый простой способ понять, кто именно создаёт нагрузку.
Автозагружаемые опции в таблице options
Одна из частых причин медленной админки и долгой загрузки фронтенда — слишком большой объём автозагружаемых опций. WordPress подгружает их почти на каждом запросе, поэтому если в wp_options накопилось много тяжёлых значений, сайт начинает работать медленнее даже без явной ошибки в теме.
Проверять это нужно аккуратно, особенно на живом сайте. Сначала сделайте резервную копию базы данных. Потом посмотрите, какие опции занимают больше всего места и действительно ли они должны загружаться автоматически. Часто там оказываются следы старых плагинов, кэшированных данных или больших сериализованных массивов.
Если вы не уверены, что именно можно менять, не редактируйте записи вручную наугад. Без понимания назначения опции легко сломать настройки темы или плагина. В таких случаях безопаснее сначала определить источник через поиск по базе или временное отключение плагина, который создал эти данные.
Сократите число запросов без изменения логики сайта
Не всегда нужно переписывать шаблоны. Иногда достаточно изменить способ получения данных и убрать повторяющиеся обращения к базе.
Используйте кэш там, где данные не меняются каждую секунду
Если страница каждый раз собирает одни и те же данные — меню, список рубрик, блок популярных записей, настройки темы — имеет смысл кэшировать результат. В WordPress для этого обычно используют объектный кэш, а на уровне приложения — transient API.
Transient подходит для данных, которые можно обновлять периодически, а не при каждом запросе. Например, список популярных записей за сутки или набор элементов для виджета. Тогда WordPress не будет заново собирать эти данные при каждой загрузке страницы.
Если на хостинге доступен persistent object cache, например Redis или Memcached, это ещё лучше: часть повторяющихся обращений перестаёт идти в MySQL вообще. Но здесь важно понимать, что сам по себе плагин кэша не решает проблему плохого шаблона. Он лишь помогает, если данные действительно можно переиспользовать.
Не вызывайте тяжёлые функции там, где достаточно уже загруженных данных
WordPress часто уже подгружает нужную информацию вместе с основным запросом. Если шаблон дополнительно делает отдельные запросы к тем же данным, это лишняя работа. Особенно это заметно в списках записей, где на каждую карточку отдельно запрашивают метаданные, изображения, термины и автора.
Практический подход такой: сначала посмотреть, какие данные уже есть в объекте записи, а потом использовать их вместо повторных обращений. Это особенно полезно в кастомных темах и дочерних темах, где шаблоны часто собирались вручную и без учёта нагрузки.
Оптимизируйте базу, если она уже разрослась
Даже хороший код будет работать хуже, если база данных давно не чистили. Но здесь важно не путать оптимизацию с «магической уборкой». Сама по себе очистка не уменьшит число запросов, если тема продолжает делать лишние обращения. Зато она может сократить время ответа MySQL и убрать часть задержек.
Что обычно имеет смысл проверить:
- ревизии записей, если их слишком много;
- автосохранения и временные данные, которые уже не нужны;
- спам и удалённые комментарии;
- старые transient-значения;
- остатки удалённых плагинов в
wp_optionsи других таблицах.
Если база большая, не запускайте агрессивную очистку без резервной копии. На некоторых сайтах удаление «лишнего» приводит к потере нужных настроек или к сбою плагина, который всё ещё использует старые записи.
Проверьте, что нагрузка действительно снизилась
После изменений важно не гадать, а сравнить результат. Иначе легко принять за улучшение обычное колебание нагрузки на сервере.
Проверяют обычно три вещи:
- общее число запросов на странице до и после изменений;
- время выполнения самых медленных запросов;
- ощущаемую скорость админки и фронтенда на типовых страницах.
Если вы включали SAVEQUERIES, сравните список запросов на проблемной странице. Если использовали плагин профилирования, посмотрите, какие запросы исчезли или стали реже. Если на сайте есть серверный кэш или объектный кэш, проверьте, уменьшилось ли число обращений к MySQL при повторной загрузке той же страницы.
Полезно тестировать не только главную, но и страницы, которые обычно создают нагрузку: архивы, карточки записей, поиск, страницы с фильтрами и админку с большим количеством метабоксов. Именно там лишние запросы проявляются сильнее всего.
Что обычно даёт наибольший эффект
Если нужен короткий план без лишней теории, начинайте с этого порядка:
- найти страницу или раздел, где MySQL нагружается сильнее всего;
- отключить или ограничить тяжёлые плагины;
- убрать повторные запросы в теме и шаблонах;
- сократить автозагружаемые опции;
- включить кэширование для данных, которые не меняются постоянно;
- проверить и почистить базу, если она давно не обслуживалась.
Если сайт сделан на стандартной теме и с минимальным набором плагинов, проблема часто решается именно на уровне шаблонов и кэша. Если же проект давно оброс расширениями, сначала ищите лишние запросы в плагинах и в таблице wp_options. Это самые частые источники нагрузки, которые можно убрать без полной переделки сайта.