Если WordPress стал медленным, причина не обязательно в большом количестве плагинов. Страница может долго ждать ответа сервера из-за PHP-кода или базы данных, а может быстро получить HTML, но медленно загружать изображения и скрипты. Чтобы не отключать всё подряд, сначала определите, на каком этапе возникает задержка, а затем меняйте по одному фактору.
Сначала выясните, что именно тормозит
Проверьте несколько страниц: главную, запись или страницу с типичным содержимым и, если проблема есть в админке, экран, который открывается медленно. Повторите проверку в приватном окне без входа в WordPress и сравните результат с авторизованным просмотром. Вход в админку часто отключает кэширование для пользователя, поэтому сайт может казаться медленнее только после авторизации.
Затем откройте инструменты разработчика браузера, вкладку «Сеть» (Network), включите сохранение журнала и перезагрузите страницу. Посмотрите на запрос документа — обычно это запрос типа document. Если он долго ждёт ответа сервера, задержка возникает до получения HTML. Если документ приходит быстро, а страница визуально собирается долго, проверьте загрузку изображений, CSS и JavaScript: проблема может быть в тяжёлых ресурсах, а не в PHP или запросах WordPress.
Для сравнения замерьте одну и ту же страницу несколько раз. Результат может меняться из-за кэша, внешних сервисов и нагрузки на сервер. Инструменты вроде PageSpeed Insights полезны для оценки загрузки страницы и ресурсов, но сами по себе не укажут, какой именно плагин или запрос замедляет WordPress.
Проверьте, не ограничивает ли сайт хостинг
Если долго отвечает документ на разных страницах, в том числе на простых, сначала проверьте состояние сервера. В панели хостинга найдите графики использования CPU и памяти, лимиты PHP-процессов и сообщения о превышении ресурсов. Названия показателей зависят от провайдера. Если задержки совпадают с пиками нагрузки или сайт регулярно упирается в лимиты, причина может быть в тарифе, соседней нагрузке на сервер или недостатке ресурсов.
Сравните время ответа в разные часы и проверьте, затрагивает ли проблема весь сайт. Резкое замедление только в определённые периоды, ошибки 5xx или сообщения о нехватке памяти — повод передать хостингу время и адреса запросов, когда это происходило. Попросите проверить нагрузку на аккаунт, лимиты PHP, ошибки PHP и медленные запросы к базе данных. Доступ к журналам и медленным запросам зависит от тарифа и настроек сервера.
Если хостинг показывает нормальные ресурсы, это не доказывает, что сервер ни при чём: кратковременную перегрузку график может не отразить. И наоборот, высокая нагрузка CPU не всегда означает проблему тарифа — её может создавать конкретный плагин или операция WordPress. Сопоставляйте показатели с результатом тестов и временем появления проблемы.
Найдите тяжёлые запросы и участки PHP
Для проверки на сайте можно временно установить Query Monitor. Плагин показывает запросы к базе данных, их длительность и вызвавший их компонент, а также PHP-ошибки, хуки, HTTP-запросы и другую информацию о текущей загрузке страницы. После установки откройте медленную страницу под учётной записью администратора и изучите панели Query Monitor.
Обращайте внимание не только на общее число запросов. Важнее запросы с большой длительностью, повторяющиеся запросы, предупреждения и компонент, который их вызвал: плагин, тема или ядро WordPress. Если один запрос явно выделяется, проверьте его источник и условия выполнения. Большое число запросов само по себе ещё не доказывает, что именно они вызывают заметное замедление.
Query Monitor добавляет диагностическую нагрузку, а его результаты относятся к конкретной странице и конкретному пользователю. Сравнивайте одинаковые страницы в одинаковых условиях и после диагностики удалите плагин, если он больше не нужен. Не публикуйте скриншоты панели на открытом сайте: в диагностических данных могут быть сведения о структуре сайта и запросах.
Если задержка связана с внешним HTTP-запросом, например проверкой обновлений или обращением к стороннему API, Query Monitor может помочь найти компонент, который его инициирует. Но сам источник может быть недоступен или медленно отвечать вне вашего сервера. В таком случае проверьте журнал ошибок и настройки интеграции, а не ограничивайтесь оптимизацией базы данных.
Проверьте плагины и тему без риска для посетителей
Отключение плагинов на рабочем сайте может нарушить формы, оплату, личный кабинет и другие функции. Поэтому для изоляции причины используйте тестовую копию сайта. Если её нет, сначала создайте резервную копию и уточните у хостинга, как восстановить сайт. Не проводите массовое отключение на продакшене, если не готовы быстро вернуть прежнюю конфигурацию.
На тестовой копии отключите плагины и повторите замеры на тех же страницах. Если скорость заметно меняется, включайте плагины по одному или небольшими группами, пока задержка не появится снова. Так вы сузите круг поиска. Проверяйте не только отдельные плагины: иногда проблема возникает из-за их взаимодействия или проявляется лишь при определённой настройке.
Для временной диагностики можно использовать режим устранения неполадок плагина Health Check & Troubleshooting: он позволяет отключать плагины и переключать тему только для текущей учётной записи администратора, не меняя вид сайта для обычных посетителей. Но этот режим не заменяет проверку на копии: он может не воспроизвести поведение, зависящее от кэша, сторонних сервисов или действий посетителя. Перед изменениями убедитесь, что используете актуальную версию плагина и понимаете, как выйти из режима диагностики.
Чтобы проверить тему, на тестовом сайте временно переключитесь на стандартную тему WordPress. Если страницы после этого стали заметно быстрее при неизменных плагинах, изучите функции текущей темы, её шаблоны и дополнительные запросы. Одна только смена темы не доказывает, что виновата тема: она может отключить связанные с ней виджеты, скрипты или функции. Сравнивайте одинаковый набор страниц и проверяйте, что именно изменилось.
Как различить проблему кода и сервера
Соберите результаты в простую картину. Она поможет выбрать следующий шаг, а не гадать по одному показателю.
- Долго ждёт ответа HTML на всех страницах: проверьте ресурсы хостинга, PHP-ошибки, Query Monitor и обращения к базе данных. Причиной может быть и сервер, и код, который выполняется на каждом запросе.
- Медленная только одна страница: сравните её запросы и компоненты с быстрой страницей. Часто замедление связано с конкретным шаблоном, виджетом, запросом к базе или обработкой большого набора данных.
- Документ приходит быстро, но страница долго отображается: изучите изображения, JavaScript, CSS, шрифты и сторонние ресурсы во вкладке Network. Переключение хостинга не исправит тяжёлые файлы на странице.
- Медленно только в админке: проверьте именно проблемный экран, активные плагины и запросы, которые выполняются для администратора. Скорость публичных страниц не всегда отражает работу панели управления.
- Замедление появляется периодически: сопоставьте время с графиками нагрузки и журналами хостинга. Причиной может быть пик запросов, фоновая задача или нестабильность внешнего сервиса.
Не делайте вывод о сервере только по одному замеру и не оценивайте производительность по одной цифре PageSpeed. Важны повторяемость результата, одинаковые условия и конкретный этап, на котором возникает ожидание.
Повторите замер после изменений
После исправления проверьте те же страницы тем же способом, что и до него: с одинаковым статусом входа, браузером и состоянием кэша. Если кэш сайта или сервера очищался, учитывайте, что первый запрос после очистки может быть медленнее последующих. Сравните несколько повторов и убедитесь, что нужные функции сайта по-прежнему работают.
Если тесты указывают на ограничение хостинга, а плагины, тема и запросы не объясняют задержку, передайте провайдеру результаты замеров, время возникновения проблемы и сообщения из журналов. Если же задержка воспроизводится на тестовой копии с конкретным компонентом, сначала решайте вопрос с его настройкой, заменой или исправлением. Такой порядок помогает отличить ограничение сервера от проблемы в WordPress и не менять инфраструктуру наугад.