Как найти плагин, который тормозит сайт WordPress
Сайт грузится по 10 секунд, админка открывается минуту, а клиенты жалуются на зависания. Первое, на что грешат — хостинг. Но в 80% случаев причина даже не в хостинге, а в одном-двух плагинах, которые жрут ресурсы безбожно. Разберу 3 метода найти виновника — от простого к надёжному.
Медленный плагин можно вычислить за 15 минут. Query Monitor показывает нагрузку каждого плагина в реальном времени. Плагин с PHP Time >0.2с или Query Count >50 — кандидат на замену. Есть и ручной метод: включить отладку PHP (WP_DEBUG) и замерить время загрузки с каждым плагином по очереди. Третий — профилирование через Xdebug или Blackfire, но это для сложных случаев. Начните с первого.
Почему сайт тормозит: 4 главные причины
1. Жирные конструкторы страниц
Elementor, WPBakery, Divi — это уже не просто плагины, а фреймворки. Каждый добавляет свой слой поверх WordPress: свои шорткоды, свои таблицы в БД, свои стили и скрипты. Elementor с 10+ виджетами на странице легко генерирует 50-80 SQL-запросов. И это на странице, где можно обойтись чистым Gutenberg с 5 блоками.
2. Плагины с постоянной фоновой нагрузкой
Некоторые плагины не ждут, пока пользователь откроет страницу — они работают постоянно. Плагины бекапов проверяют расписание каждые 5 секунд. SEO-плагины пересчитывают счётчики. Кэширующие плагины сбрасывают кэш при каждом сохранении. Всё это — нагрузка на PHP и MySQL, которая суммируется.
3. Кэширующие плагины без настройки
Ирония: кэширующий плагин, который неправильно настроен, сам становится причиной тормозов. WP Super Cache без Preload Mode генерирует страницу для каждого посетителя. W3 Total Cache с включённой Database Cache без Memcached — молотит БД впустую. WP Rocket — хорош, но и он может конфликтовать с другими плагинами кэширования на хостинге.
4. Плагины с тяжёлыми внешними запросами
Если плагин при каждом открытии страницы стучится к внешнему API (Google Fonts, reCAPTCHA, аналитика соцсетей), а API отвечает с задержкой — страница будет грузиться, пока не получит ответ. Особенно критично для России: Google Fonts без CDN или кэша — гарантированный TTFB в 5+ секунд (об этом уже писал в статье Google Fonts не грузятся в РФ).
Метод 1: Query Monitor — 15 минут и готово
Query Monitor — бесплатный плагин, который показывает, что происходило на странице во время генерации. Он не добавляет нагрузку на сайт для обычных посетителей (админ-бар видите только вы).
Установка и первый запуск
- Установите Query Monitor через админку: Плагины → Добавить → найти Query Monitor.
- Активируйте — появится панель в админбаре (только для залогиненных админов).
- Откройте проблемную страницу (ту, что грузится дольше всего).
- Нажмите на цифру в админбаре — откроется детальная панель.
Особенно часто тормозят: WooCommerce (на страницах без товаров — до 40 лишних запросов), Rank Math (если включены 100500 аналитических модулей), плагины мульти-язычности (каждый перевод — отдельный SQL).
Метод 2: Отладка через WP_DEBUG — без плагинов
Если не хотите ставить Query Monitor (или он сам конфликтует с сайтом), используйте ручной метод. Он точнее, но дольше.
Включаем отладку
Откройте wp-config.php (в корне WordPress, доступ через FTP или файловый менеджер хостинга). Найдите строку:
define('WP_DEBUG', false);Замените на:
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);Измеряем время
После включения отладки добавьте в footer.php вашей темы (перед закрывающим </body>):
<?php if (current_user_can('administrator')) {
echo '<!-- Время: ' . timer_stop(0) . ' сек. Запросов: ' . get_num_queries() . ' -->';
} ?>На Beget и других хостингах с Nginx этот код по-прежнему работает — он выполняется на стороне PHP, до передачи ответа.
Метод 3: Профилирование — для глубокой диагностики
Если Query Monitor и ручная отладка не дали результата, а сайт всё ещё тормозит — нужен профилировщик PHP. Это инструмент, который записывает каждый вызов функции и время её выполнения.
Бесплатные варианты:
- Xdebug — установить на VPS через apt (на shared-хостингах вроде Beget, Timeweb не работает — нет доступа к php.ini).
- Blackfire.io — есть модуль для PHP, работает поверх Xdebug. Платный, но с бесплатным лимитом.
- PHP Built-in profiler (PHP 8.4+) — можно включить через php.ini: `zend_extension=tideways.so`. На Beget недоступно, но для VPS — вариант.
Проверка результата
- Замерьте время загрузки до: PageSpeed Insights (любая метрика), GTmetrix (время полной загрузки), Query Monitor (PHP Time).
- Отключите/замените подозреваемый плагин.
- Замерьте время после — разница должна быть 30-200% (если плагин был реально проблемный).
- Проверьте контент страницы: ничего не сломалось? Если да — найдите альтернативу (аналог плагина с тем же функционалом, но легче).
Когда способ не сработает
Тормозит не PHP, а БД
Query Monitor показывает мало времени PHP, но много запросов. Проблема может быть в таблицах wp_options (мусор после удаления плагинов) или wp_postmeta (тысячи записей от WooCommerce). Решение: очистить ревизии, транзиенты и спам-комментарии — я уже писал как это сделать без плагинов.
Плагин не тормозит, а сайт еле дышит
Хостинг. На самом дешёвом тарифе Beget (или Timeweb) 2-4 сайта с WooCommerce могут упираться в 256MB памяти. Решение: миграция на VPS (FirstVDS, RUVDS от 500₽) или хотя бы смена тарифа.
Плагинов 50+, и каждый по чуть-чуть
Бывает, что нет одного жирного — каждый добавляет 0.05 сек и 3 запроса. Суммарно — 2.5 сек и 150 запросов. Тут поможет только аудит: пройтись по каждому плагину и решить — нужен ли он вообще. Часто оказывается, что 15 плагинов можно заменить куском кода в functions.php.
Тормозит внешний API/Script
Например, Google Fonts грузится через API и блокирует рендеринг. Query Monitor этого не покажет — это не PHP. Смотрите вкладку Network в Chrome DevTools. Решение: загружать шрифты локально, отключить внешние скрипты, где возможно.
Частые вопросы
FAQ
Нужна помощь с оптимизацией WordPress?
Найду и устраню причину тормозов: заменю тяжёлые плагины, настрою кэш, оптимизирую БД. Результат — время загрузки до 2 секунд.
