Тяжёлые плагины в WordPress: как найти виновника тормозов

Один плагин может увеличить время ответа WordPress с долей секунды до нескольких секунд, но искать его отключением расширений по очереди на рабочем сайте опасно. В WordPress 6.x виновник часто проявляется только на конкретной странице: в корзине, админке, поиске или во время фоновой задачи. Ниже — практический порядок диагностики: что измерить, как использовать Query Monitor, как сравнивать результаты и что проверять после обнаружения проблемы.

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

Фраза «сайт медленный» недостаточно точна. Для разных симптомов будут разные виновники и разные измерения. Начните с четырёх сценариев:

• Медленно открываются страницы для посетителей. Проверяйте время ответа сервера, количество SQL-запросов, внешние HTTP-запросы и работу кэша.
• Тормозит админка. Смотрите экран редактора, список заказов, медиатеку и другие страницы отдельно. Плагин может почти не влиять на главную, но заметно нагружать wp-admin.
• Проблемы появляются только при оформлении заказа. Анализируйте корзину, расчёт доставки, оплату и AJAX-запросы. Кэширование здесь часто отключено, поэтому тяжёлый код заметнее.
• Сайт замедляется периодически. Проверяйте WP-Cron, импорт товаров, отправку писем, резервное копирование и задачи, которые выполняются вне обычного запроса посетителя.

Зафиксируйте минимум три показателя: время ответа сервера, время полной загрузки страницы и число SQL-запросов. Снимайте их на одной и той же странице, в одном браузере и при одинаковом состоянии кэша. Иначе вы сравните не плагины, а разные условия теста.

Цель диагностики — не найти плагин с самым большим размером папки. Важен тот, кто добавляет задержку именно в проблемном сценарии.

Подготовьте безопасный тест

Лучший вариант — копия сайта на staging-сервере. Если её нет, используйте режим диагностики, который временно отключает плагины только для вашей учётной записи, не меняя сайт для посетителей. Такой режим есть, например, в плагине Health Check & Troubleshooting; перед установкой проверьте совместимость с вашей версией WordPress и сделайте резервную копию.

Не начинайте с массового отключения расширений на продакшене. Так можно сломать оплату, авторизацию, отправку писем, SEO-разметку или фоновые задания. Особенно осторожно работайте с плагинами безопасности, кеширования, резервного копирования и интернет-магазина.

Что записать до эксперимента

• версию WordPress 6.x, PHP и активной темы;
• список активных плагинов и их версии;
• URL проблемной страницы и точные шаги для воспроизведения;
• результаты двух-трёх одинаковых замеров;
• включён ли серверный, объектный или плагинный кэш.

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

Сноска. TTFB (Time to First Byte) — время от отправки запроса до первого байта ответа сервера. Высокий TTFB указывает на задержку до начала загрузки страницы, но сам по себе не доказывает, что виноват плагин.

Три способа найти источник задержки

У методов разная точность и цена риска. На практике их используют последовательно, а не выбирают один навсегда.

Разбор через Query Monitor

Query Monitor подходит для первого прохода по WordPress 6.x. Установите его из официального каталога или через панель сайта, затем откройте проблемную страницу под учётной записью администратора. Панель диагностики доступна в верхней панели WordPress, а посетители сайта её не видят.

1. Сравните время и количество запросов

Откройте раздел с общей информацией о запросе и запишите время генерации страницы, число SQL-запросов и объём памяти. Большое количество запросов не всегда означает ошибку: важнее медленные запросы и то, какой компонент их создал.

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

2. Проверьте внешние HTTP-запросы

Плагин может ждать ответа от CRM, платёжного шлюза, сервиса доставки, API аналитики или лицензирования. В разделе HTTP-запросов смотрите адрес, время ожидания и количество вызовов. Один внешний запрос на несколько секунд часто объясняет медленную админку лучше, чем десятки быстрых SQL-операций.

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

3. Посмотрите хуки, ошибки и предупреждения

Вкладки с хуками и действиями помогают увидеть активность плагина на конкретном запросе. Сама по себе длинная цепочка хуков не доказывает проблему: важны время выполнения и повторяемость.

В PHP-ошибках ищите предупреждения, фатальные ошибки и сообщения о невозможности подключиться к базе или внешнему сервису. После включения журналирования не оставляйте подробный вывод ошибок доступным посетителям. В рабочей среде ошибки должны записываться в лог, а не показываться на странице.

Проверяйте гипотезу, а не подозрение

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

1. Повторите базовый тест. Откройте одну и ту же страницу несколько раз и запишите медианный результат, а не лучший случай.
2. Включите режим диагностики. Оставьте активной тему и плагины, необходимые для воспроизведения сценария, остальные временно отключите только для своей сессии.
3. Проверьте подозреваемый плагин отдельно. Если после его отключения задержка исчезла, включите его обратно и повторите тест ещё раз.
4. Проверьте связку. Оставьте проблемный плагин активным и по очереди отключите его интеграции, дополнения и плагины, которые меняют те же хуки или таблицы.
5. Сравните логи. Убедитесь, что вместе с замедлением исчезли соответствующие SQL-запросы, HTTP-вызовы или ошибки.

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

Что обычно ломает производительность

Запросы к базе на каждой странице

Плагин может загружать настройки, метаданные или список объектов при каждом запросе. На небольшом сайте это незаметно, но объём таблиц и число товаров растут — и тот же код начинает занимать заметное время. Проверьте, есть ли у расширения настройка ограничения по типам записей, страницам или ролям пользователей.

Синхронизация внутри запроса посетителя

Импорт каталога, проверка лицензии или запрос к стороннему API не должны блокировать обычную страницу без необходимости. Если плагин поддерживает расписание, очередь или пакетную обработку, используйте их. Перенос задачи в WP-Cron не делает её автоматически быстрой: при большом объёме данных расписание нужно контролировать отдельно.

Конфликт нескольких оптимизаторов

Два плагина кэширования, несколько средств оптимизации JavaScript или пара систем SEO могут выполнять одну работу дважды. В результате появляются не только задержки, но и повреждённая разметка, ошибки в корзине и непредсказуемый кэш. Оставьте один инструмент для каждой функции и проверьте порядок его интеграции с CDN и сервером.

Медленная админка вместо медленного фронтенда

Панели статистики, конструкторы страниц, импортеры и плагины резервного копирования часто нагружают только wp-admin. Не удаляйте их из-за медленной админки, пока не проверили, не выполняют ли они тяжёлые операции по расписанию или при открытии конкретного раздела.

Когда отключать, обновлять или заменять плагин

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

Замену стоит рассматривать, когда расширение давно не обновляется, не совместимо с текущей версией WordPress или делает обязательные внешние запросы без тайм-аутов и кэширования. Перед заменой составьте список функций, которые уже используются: удаление плагина может оставить данные в базе или сломать ссылки на его типы записей.

Где диагностика даёт ложный результат

• Кэш скрывает проблему. Посетитель получает готовую страницу, а авторизованный администратор — динамическую. Тестируйте оба режима.
• Проблема находится за пределами WordPress. Медленный DNS, перегруженный PHP-FPM, база данных или диск могут замедлять любой плагин одинаково.
• Задержка возникает только под нагрузкой. Одиночный замер не покажет исчерпание CPU, памяти или числа PHP-воркеров.
• Локальная копия отличается от продакшена. Другой объём базы, версия PHP и набор расширений могут полностью изменить результат.

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

Что делать дальше

Сохраните базовые замеры и заведите простой журнал изменений: дата, версия плагина, состояние кэша, URL, время ответа и результат теста. После исправления наблюдайте не только за скоростью страницы, но и за ошибками PHP, временем выполнения фоновых задач, числом медленных SQL-запросов и отказами внешних API.

Следующий практический шаг — повторить проверку после ближайшего обновления WordPress, PHP или плагинов. Производительность в WordPress меняется не только из-за одного расширения: новая версия темы, рост каталога или изменение ответа внешнего сервиса могут вернуть старую проблему в другом месте.