Какой плагин тормозит сайт: как измерить вклад каждого
Query Monitor, отключение по одному, замер TTFB и числа запросов. Как найти плагин, который съедает секунду на каждой странице.
Содержание
Виновника ищут не перебором по одному, а делением пополам: отключить половину плагинов, замерить, отключить половину оставшихся. На тридцати плагинах это пять шагов вместо тридцати. Мерить надо время генерации страницы, гоняя замер 8-10 раз и беря медиану.
PageSpeed показывает 42 балла, ниже красной черты. Владелец сайта начинает отключать плагины наугад: сначала слайдер, потом виджет соцсетей, потом форму обратной связи. Через час балл поднимается с 42 до 46, а какой из тридцати установленных плагинов реально тормозит страницу, так и остаётся загадкой. Эта статья для тех, кто подозревает конкретный плагин, но не хочет гадать методом отключения наугад. Разберём, как измерить вклад каждого плагина в загрузку страницы через Query Monitor, замерить TTFB до и после, и что делать, если виновник нужен сайту и удалить его нельзя.
Почему PageSpeed показывает симптом, а не виновника
PageSpeed Insights и Lighthouse честно измеряют результат: сколько весит страница, сколько миллисекунд браузер ждёт первый байт, сколько скриптов блокируют рендер. Но они смотрят на страницу снаружи, глазами браузера, и не видят, что происходит на сервере до того, как первый байт HTML вообще ушёл посетителю. Если плагин делает пять лишних SQL-запросов на каждой загрузке или синхронно стучится на внешний API проверки лицензии, Lighthouse честно покажет высокий TTFB и низкий балл, но не укажет, какой из тридцати установленных плагинов в этом виноват.
Рекомендации вида «уменьшите неиспользуемый JavaScript» или «устраните код, блокирующий рендеринг» называют файлы, а не плагины. По пути в отчёте вроде /wp-content/plugins/some-slider/js/slider.min.js виновника иногда видно и так, но когда проблема в серверном времени генерации страницы, а не в весе фронтенда, Lighthouse вообще молчит про причину. Тут нужен другой инструмент, который смотрит изнутри WordPress, а не снаружи через браузер.
Query Monitor: что показывают вкладки
Query Monitor, бесплатный плагин из официального каталога, добавляет панель в админскую полосу сверху с временем генерации страницы, числом запросов к базе и использованием памяти. Кликнув на панель, открывается несколько вкладок, и три из них решают задачу поиска виновника напрямую.
Вкладка Queries группирует SQL-запросы по компоненту, который их вызвал, обычно по конкретному плагину или части ядра. Видно не только количество запросов, но и суммарное время на каждый компонент. Если один плагин из тридцати ответственен за 180 запросов из 240 на странице, это сразу заметно.
Вкладка Hooks & Actions показывает время выполнения каждого обработчика, повешенного на хуки WordPress. Медленные колбэки подсвечиваются, и рядом с каждым указано, из какого файла плагина он вызван.
Вкладка HTTP API calls, пожалуй, самая полезная и самая недооценённая. Она показывает все исходящие запросы, которые сервер делает во время генерации страницы: не с браузера посетителя, а с самого хостинга. У меня в практике был плагин лицензирования премиум-темы, который на каждой загрузке страницы синхронно проверял лицензию на внешнем сервере разработчика. Средний ответ сервера лицензирования 900 миллисекунд, и эти 900 миллисекунд закладывались в каждую генерацию страницы сайта, включая случаи, когда сервер лицензирования просто не отвечал вовремя, и время ожидания вырастало до нескольких секунд.
Метод половинного деления вместо перебора по одному
На сайте с пятью плагинами отключать их по одному и смотреть на результат вменяемо. На сайте с тридцатью плагинами это часы работы и риск забыть, что было включено до начала эксперимента. Быстрее работает метод половинного деления: отключаем сразу половину плагинов, измеряем, если стало заметно быстрее, виновник среди отключённых, включаем половину из них обратно и повторяем. За четыре-пять итераций из тридцати плагинов остаётся один-два подозреваемых, а не тридцать.
Проверять это на боевом сайте напрямую рискованно: пока плагины отключены, посетители видят сайт без нужной функциональности. Плагин Health Check & Troubleshooting решает именно эту проблему: он включает режим отладки только для текущей сессии администратора, обычные посетители продолжают видеть сайт с плагинами как обычно. Это безопасный способ гонять эксперименты на продакшене без реального даунтайма для пользователей.
Если такого плагина нет или сайт совсем небольшой, тестируйте на staging-копии на поддомене, снятой заранее.
Замер до и после: TTFB, число запросов, время генерации
Субъективное «вроде побыстрее стало» не считается измерением. Нужны цифры до и после каждого шага. Проще всего замерить TTFB через curl прямо из консоли:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}sn" https://example.ru/Одного запуска мало, сеть шумит: значения могут прыгать в разы между соседними запросами из-за случайной задержки на промежуточных узлах. Гоняйте команду 8-10 раз подряд и смотрите на медиану, а не на первое число, которое выпало. Ещё надёжнее число из самого Query Monitor: он показывает время генерации страницы серверным таймером, без сетевого шума между вами и сервером вообще.
Второй параметр для сравнения, число SQL-запросов на страницу. Для типичной статьи блога на WordPress с парой виджетов это 20-40 запросов. Если Query Monitor показывает 200 и больше, почти наверняка где-то плагин делает запрос в цикле вместо одного агрегированного запроса, классическая ошибка N+1.
Типовые пожиратели времени
Не все плагины одинаково опасны для скорости. По опыту чаще всего тормозят несколько категорий.
- Слайдеры и карусели. Revolution Slider и подобные грузят собственный набор JS и CSS на каждой странице сайта, даже там, где слайдера физически нет на экране.
- Конструкторы страниц. Elementor, Divi и аналоги добавляют общий фреймворк стилей и скриптов сайту целиком, а не только тем страницам, которые собраны в конструкторе.
- Виджеты похожих и популярных записей без кэша. Каждый такой виджет это отдельный тяжёлый SQL-запрос с сортировкой по просмотрам или похожести, который пересчитывается заново при каждой загрузке страницы вместо того, чтобы кэшироваться на час.
- Статистика посещений внутри самой админки WordPress (не путать с внешней аналитикой вроде Метрики). Такие плагины пишут в базу при каждом визите и на большом трафике превращаются в постоянную нагрузку на запись.
- Антиспам-виджеты и формы с синхронной проверкой через внешний API прямо при рендере страницы, а не только при отправке формы.
Таблица примерных потерь времени по категориям, по моим замерам на разных клиентских сайтах:
| Категория плагина | Типичная потеря на TTFB | Как проявляется |
|---|---|---|
| Слайдер с автозагрузкой везде | 150-400 мс | Лишние JS/CSS на каждой странице |
| Конструктор страниц (общий фреймворк) | 200-600 мс | Тяжёлые стили и скрипты сайта целиком |
| Похожие записи без кэша | 100-500 мс | SQL-запрос с сортировкой на каждой загрузке |
| Внешняя проверка лицензии/API синхронно | 300-1500 мс | Видно во вкладке HTTP API в Query Monitor |
| Статистика посещений в БД | 50-300 мс | Растёт вместе с трафиком, незаметно сначала |
Что делать, если плагин нужен
Не каждый тяжёлый плагин нужно сразу удалять. Если функциональность действительно нужна, есть три рабочих способа снизить цену.
Кэшировать результат работы плагина отдельно от общего кэша страниц. Для виджета похожих записей это может быть транзиент WordPress на час вместо пересчёта на каждой загрузке:
$related = get_transient('related_posts_' . get_the_ID());
if (false === $related) {
$related = get_related_posts_query(get_the_ID());
set_transient('related_posts_' . get_the_ID(), $related, HOUR_IN_SECONDS);
}Загружать скрипты и стили только там, где они реально используются, через условие в wp_enqueue_scripts, а не сайтом целиком. Многие плагины по умолчанию подключают свои файлы везде, потому что так проще разработчику плагина, а не потому что так нужно вашему сайту.
Заменить синхронный внешний вызов на асинхронный или кэшированный. Проверка лицензии раз в сутки в фоне через wp_cron вместо проверки на каждой загрузке страницы решает проблему полностью, просто не все плагины дают такую настройку, и тогда встаёт вопрос замены плагина на альтернативу или написания 20-30 строк своего кода на замену узкой функции.
Чек-лист диагностики по шагам
Если коротко, вот порядок действий целиком, без лишних прыжков между инструментами:
- Установить Query Monitor, открыть любую тяжёлую страницу сайта, посмотреть суммарное время генерации и число запросов в панели сверху.
- Открыть вкладку Queries, найти компонент с наибольшим суммарным временем на SQL-запросы.
- Открыть вкладку HTTP API calls, проверить, нет ли синхронных внешних запросов при обычной загрузке страницы.
- Замерить TTFB через curl 8-10 раз подряд, зафиксировать медианное значение как точку отсчёта.
- Отключить половину плагинов (или включить режим Health Check для админской сессии) и повторить замер.
- Сузить круг подозреваемых методом половинного деления до одного-двух плагинов.
- Для найденного виновника решить: кэшировать, отложить загрузку, ограничить условием показа или заменить на код.
- Повторить замер TTFB и число запросов после исправления, зафиксировать разницу в цифрах, а не на глаз.
Такой прогон занимает 30-40 минут на сайте среднего размера и почти всегда даёт точный ответ, а не предположение.
Если после чистки и оптимизации сайт всё равно упирается в лимиты самого хостинга, это уже другая история, разобранная в статье про то, почему WordPress тормозит через три года работы. Про сам замер и что означают конкретные баллы PageSpeed, писал отдельно в статье про 30 баллов в PageSpeed Insights. Если после чистки плагинов TTFB всё ещё выше 600 мс на shared-хостинге, посмотрите разбор про TTFB на shared-хостинге, там причина обычно уже не в плагинах, а в самом тарифе. Отдельный частый виновник, о котором забывают, это счётчики аналитики: у меня есть разбор как Яндекс Метрика замедляет сайт и что с этим по-честному можно сделать.
Если разбираться с этим самостоятельно некогда, я делаю такую диагностику как разовую работу с конкретным отчётом: что именно тормозит и сколько миллисекунд экономит каждое исправление. Смотрите тарифы или пишите через форму на главной, если сайт теряет посетителей из-за скорости прямо сейчас.
Частые вопросы
Как понять, какой плагин тормозит сайт
Отключать плагины половинами и мерить время генерации страницы после каждого шага. Так виновник находится за пять итераций вместо тридцати. Отдельно помогает панель отладки, которая показывает запросы к базе по источникам.
Что именно мерить
Время до первого байта, время генерации страницы и число запросов к базе. Общий балл PageSpeed для этой задачи бесполезен: он показывает симптом, а не источник.
Какие плагины тормозят чаще всего
Слайдеры с загрузкой на всех страницах, конструкторы страниц, блоки похожих записей без кэша и всё, что синхронно ходит во внешний сервис. Последнее самое коварное: задержка зависит от чужого сервера.
Что делать, если плагин нужен
Ограничить его загрузку страницами, где он реально работает, включить кэш и убрать синхронные внешние запросы. Если не помогает, искать замену полегче или переносить функцию в тему.
