WordPress тормозит не из-за плагинов: где искать настоящую причину

2.9 секунды. Столько отдавал главную страницу сайт производителя окон под Москвой — без единого посетителя, ночью, при полностью отключённых плагинах. Владелец до этого месяц удалял всё подряд: слайдеры, формы, конструктор страниц. Оставил голую тему и WooCommerce. Стало 2.7. Он написал мне со словами «видимо, надо переезжать на другой движок».

Переезжать не пришлось. Через сорок минут диагностики нашлась таблица wp_options, в которой на автозагрузке висело 9,4 мегабайта данных. Каждый визит, каждый вызов админки, каждый запрос робота Яндекса заставлял PHP тянуть эти 9 мегабайт из базы и разворачивать их в память. Плагины, которые их туда положили, были удалены полгода назад. Данные остались.

Это не редкий случай. Я разбираю такие сайты постоянно, и картина повторяется: человек винит плагины, потому что про плагины пишут во всех статьях про скорость. А настоящий тормоз сидит на уровне, до которого «отключить и посмотреть» просто не добирается.

«Отключил все плагины — сайт всё равно грузится 3 секунды»

Совет «отключите плагины» работает ровно в одном сценарии: когда конкретный плагин делает что-то тяжёлое прямо во время генерации страницы. Такое бывает — например, плагин выгрузки в маркетплейсы, который на каждом хите синхронизирует остатки. Но это меньшинство случаев.

Проблема в том, что отключение плагина не отменяет его следов. Плагин выключен, а его настройки, кэши, transient-записи и накопленные логи продолжают лежать в базе. Дальше:

• записи с флагом autoload = yes грузятся при каждом обращении, независимо от того, активен ли плагин;
• таблицы, созданные плагином (статистика просмотров, логи форм, история заказов), остаются в базе и продолжают попадать в резервные копии и в общие запросы;
• задачи, поставленные в очередь WP-Cron, никуда не деваются и пытаются выполняться;
• оставшиеся мета-поля у товаров и записей раздувают wp_postmeta, а по этой таблице ходит тема при каждой выборке.

Второй момент — методика. Отключая плагины по одному и глядя на секундомер в PageSpeed, вы измеряете сумму всего: и работу сервера, и загрузку картинок, и рендер в браузере. Разброс между двумя замерами подряд на одном и том же сайте легко достигает 30–40%. На таком шуме отличить «плагин виноват» от «повезло с моментом» невозможно.

За годы работы я вывел простое правило: если после отключения всех плагинов время ответа сервера упало меньше чем на 40% — плагины не были главной причиной. Ищите ниже.

Первое действие: разделить TTFB и отрисовку

Пока вы не разложили «три секунды» на составляющие, любая оптимизация — это стрельба вслепую. Разложить надо минимум на два блока:

• TTFB (Time To First Byte) — сколько сервер думал, прежде чем начать отдавать HTML. Это PHP, база данных, кэш, лимиты хостинга. Здесь плагины участвуют, но далеко не всегда как главный виновник.
• Отрисовка — сколько браузер грузил CSS, JS, шрифты, картинки и складывал из этого страницу. Здесь живут LCP и CLS, тяжёлые изображения, блокирующие скрипты, чужие виджеты.

Разделить их можно за минуту, без всяких сервисов. В консоли:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://ваш-сайт.ru/

Эта одна строка сразу отсекает половину гипотез. Смотрите на разницу между tls и ttfb — это чистое время работы PHP и базы. Ориентиры, которыми я пользуюсь:

TTFB	Что это значит	Куда копать
до 200 мс	Норма, кэш работает	Проблема во фронтенде: картинки, скрипты, шрифты
200–500 мс	Приемлемо, но есть запас	Настройка кэша, OPcache, объектный кэш
500–1200 мс	PHP реально работает на каждом хите	Кэш не срабатывает или база отвечает медленно
свыше 1200 мс	Сервер или база в тупике	autoload, лимиты хостинга, блокирующие внешние запросы

Отдельно проверьте TTFB для авторизованного пользователя и для гостя, а также для главной и для карточки товара. Если для гостя 180 мс, а для админа 2,4 секунды — кэш работает, и вы измеряли не то. Если у главной 150 мс, а у карточки товара 1,9 секунды — проблема в шаблоне карточки, а не в сайте целиком.

wp_options и автозагрузка — причина, которую находят последней

Это моя причина номер один по частоте. WordPress при каждой загрузке страницы выполняет запрос вида SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' и складывает всё это в память. Так задумано: движок предполагает, что там лежит пара сотен килобайт настроек.

Что там оказывается в реальности через два-три года жизни сайта: сериализованные массивы настроек конструктора страниц, кэши курсов валют, выгрузки каталогов, логи писем, «временные» данные плагинов аналитики, остатки от четырёх сменённых тем. Я видел 47 мегабайт на автозагрузке. Сайт открывался 11 секунд, владелец был уверен, что это хостинг.

Проверяется одним запросом в phpMyAdmin или через консоль:

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb FROM wp_options WHERE autoload = 'yes';

И вторым — чтобы увидеть конкретных виновников:

SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC LIMIT 30;

Здоровое значение — до 800 килобайт. Всё, что выше двух мегабайт, надо разбирать поимённо. Дальше действуете так: опции от удалённых плагинов удаляете, опции работающих плагинов, которые не нужны на каждой странице, переводите в autoload = 'no'. Перед этим — резервная копия базы, обязательно. Один неаккуратный DELETE по wp_options способен положить сайт целиком.

Соседняя история — «протухшие» transient-записи. Они должны удаляться сами, но при отключённом или сломанном WP-Cron копятся месяцами:

SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '\_transient\_%';

Сорок тысяч строк — не редкость. По сути, база превращается в свалку, а движок каждый раз ходит по этой свалке.

Хостинг, который душит вас лимитами (и молчит об этом)

Второй по частоте виновник, и самый неочевидный, потому что снаружи его не видно. На виртуальном хостинге ваш сайт живёт с сотней соседей и получает квоту на процессорное время, память, число одновременных процессов и операции с диском. Когда квота исчерпана, сервер не выдаёт ошибку — он просто ставит ваши запросы в очередь. Для посетителя это выглядит как «сайт тормозит», причём непредсказуемо: утром летает, вечером зависает.

На чём это ловится:

• Плавающий TTFB. Замерьте curl-ом двадцать раз подряд с интервалом в минуту. Если разброс от 300 мс до 3 секунд без изменения нагрузки — это троттлинг, а не код.
• Панель хостинга. На CloudLinux в панели есть статистика LVE: «CPU limit reached», «EP limit», «IO limit». Смотрите за неделю. Если упираетесь в потолок ежедневно — оптимизация кода даст вам 20%, а смена тарифа 300%.
• Логи веб-сервера. Ошибки server reached pm.max_children в логе PHP-FPM означают, что процессы кончились и запросы ждут в очереди.

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

И третья вещь, которую почти никто не проверяет: где физически стоит сервер. Если аудитория в России, а хостинг в Германии или в Нидерландах, вы платите 60–90 мс на каждом соединении просто за расстояние. Для Яндекса, который меряет реальные тайминги пользователей, это не мелочь. Когда я делаю технический аудит сайта по 120+ параметрам, география хостинга — один из первых пунктов чек-листа.

WP-Cron, внешние HTTP-запросы и другие «невидимые» задержки внутри рендера

WordPress по умолчанию не использует системный планировщик. Вместо этого он проверяет очередь задач при обращении посетителя: пришёл человек — движок посмотрел, не пора ли что-нибудь выполнить. Пока задач мало, это незаметно. Когда в очереди висят выгрузка каталога, рассылка, проверка обновлений и три задачи от давно удалённого плагина, посетителю, которому «повезло», страница отдаётся на секунду-полторы дольше.

Лечится в две строки. В wp-config.php:

define('DISABLE_WP_CRON', true);

И системная задача в панели хостинга раз в 5–15 минут на wp-cron.php. Всё, случайные посетители больше не оплачивают ваши фоновые задачи своим временем.

Вторая невидимая задержка — внешние HTTP-запросы прямо во время генерации страницы. Тема или плагин обращается к стороннему серверу: проверить лицензию, забрать курс валют, подтянуть отзывы, дёрнуть API доставки. Пока внешний сервер отвечает, ваш PHP стоит и ждёт. Если тот сервер лёг или отвечает за 5 секунд — ваш сайт отвечает за 5 секунд. Я разбирал сайт, который встал намертво, потому что упал сервер лицензий у разработчика темы. Никто не менял ни строчки кода.

Найти такие запросы проще всего плагином Query Monitor — он показывает вкладку HTTP API Calls с адресами и временем каждого обращения. Дальше либо кэшируете ответ, либо переносите его в фоновую задачу, либо выкидываете.

Третье — Heartbeat API. В админке WordPress раз в 15 секунд стучится в admin-ajax.php. Если у вас пять человек постоянно сидят в админке с открытыми страницами, это ощутимая постоянная нагрузка на сервер, которая замедляет и публичную часть.

Кэш, который есть, но не работает

Классика: плагин кэширования установлен, галочки стоят, владелец уверен, что кэш работает. А кэш не отдаётся ни разу. Причины стабильно одни и те же:

• Куки посетителя ломают кэш. Почти все плагины кэширования по умолчанию отдают динамику авторизованным пользователям и тем, у кого есть определённые куки. Виджет обратного звонка или онлайн-чат, который ставит свою куку каждому гостю, выключает кэш для всех.
• UTM-метки создают отдельные версии. Каждый рекламный переход генерирует уникальный URL. Кэш плодится, попаданий нет. Метки надо игнорировать в правилах кэширования.
• Корзина WooCommerce. Стандартный механизм cart-fragments дёргает AJAX-запрос на каждой странице магазина, и вместе с ним часто отключается кэширование.
• OPcache выключен. Это не плагин, это модуль PHP. Без него интерпретатор компилирует все файлы движка при каждом обращении. Разница на живых проектах — 30–50% TTFB. Проверяется в phpinfo(): секция Zend OPcache, статус «enabled».

Проверить, отдаётся ли кэш, можно тем же curl-ом с флагом -I: смотрите заголовки ответа. Большинство плагинов и серверных кэшей ставят что-то вроде x-cache: HIT или комментарий в конце HTML. Если при десяти запросах подряд вы ни разу не увидели HIT — кэша у вас нет, независимо от того, что показывает панель плагина.

Отдельно скажу про версию PHP. Сайты, которые ко мне приходят, регулярно работают на PHP 7.4, снятой с поддержки. Переход на актуальную ветку — это бесплатные 15–25% скорости и закрытые уязвимости. Ровно поэтому обновление стека я включаю в доработку сайта одним из первых пунктов, ещё до правок в шаблонах.

Запросы к wp_postmeta: как тема убивает базу без единого плагина

Самая коварная категория, потому что виновата не «лишняя» сущность, а сам шаблон, за который вы заплатили. Схема данных WordPress устроена так, что все дополнительные поля записей и товаров лежат в одной таблице wp_postmeta в виде пар «ключ — значение». У магазина на пять тысяч товаров эта таблица легко разрастается до полутора миллионов строк.

Теперь тема хочет вывести на витрине «товары со скидкой, в наличии, отсортированные по цене». Она делает выборку с условиями по meta_key и сортировкой по значению мета-поля. MySQL вынужден соединить таблицу саму с собой несколько раз и отсортировать результат без пригодного индекса. На тысяче товаров это 80 мс, на пяти тысячах — 1,8 секунды. Разработчик темы тестировал на демо-данных из двадцати товаров и проблемы не видел.

Как найти виновника точно, а не на глаз:

• включите define('SAVEQUERIES', true); в wp-config.php на время диагностики и посмотрите в Query Monitor вкладку Queries, отсортировав по времени;
• включите slow query log в MySQL с порогом 0.5 секунды и соберите статистику за сутки реального трафика;
• для самого тяжёлого запроса выполните EXPLAIN и посмотрите на количество просмотренных строк.

Лечится это тремя способами, по возрастанию сложности: добавить составной индекс, переписать выборку на таксономии вместо мета-полей, вынести результат в объектный кэш Redis. На том сайте с окнами хватило индекса и правки одного запроса в шаблоне — витрина ускорилась с 1,9 секунды до 260 мс. Плагины при этом не трогали вообще.

Порядок диагностики: как я нахожу причину за 40 минут

Порядок важнее инструментов. Если идти в этой последовательности, причина находится почти всегда, и не приходится гадать:

• Шаг 1. Замер curl-ом: главная, карточка товара, страница категории, для гостя и для авторизованного. Двадцать замеров подряд, смотрим на медиану и разброс.
• Шаг 2. Заголовки ответа: работает ли кэш вообще, есть ли HIT, какой сервер отдаёт.
• Шаг 3. Объём автозагрузки в wp_options и количество transient-записей.
• Шаг 4. phpinfo(): версия PHP, OPcache, memory_limit, max_execution_time.
• Шаг 5. Query Monitor на тестовой копии: топ-10 запросов по времени и все внешние HTTP-вызовы.
• Шаг 6. Статистика лимитов в панели хостинга за последние 7 дней.
• Шаг 7. Логи доступа: доля ботов, самые частые URL, всплески нагрузки по часам.
• Шаг 8. И только теперь — плагины. Причём не «отключить все», а посмотреть в Query Monitor, сколько времени и сколько запросов приходится на каждый.

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

Что скорость реально даёт в Яндексе, а что — нет

Здесь надо быть честным, иначе вы разочаруетесь. Скорость — это не рычаг, который поднимает сайт в топ. Это условие, без которого остальные рычаги работают вполсилы. Разложу по пунктам, что я наблюдаю на проектах.

Что скорость даёт точно:

• Поведенческие факторы. Человек, который ждал открытия страницы четыре секунды, чаще возвращается в выдачу и уходит к конкуренту. Для Яндекса возврат в поиск — сильный негативный сигнал. Ускорив сайт с 3,4 до 0,9 секунды, на одном из проектов мы получили падение отказов с 34% до 21% за месяц — при неизменном контенте.
• Скорость обхода. Робот выделяет на сайт ограниченный ресурс. Если каждая страница отдаётся секунду, за сутки он обойдёт в разы меньше, чем при 150 мс. Для магазина с десятью тысячами товаров это прямо влияет на то, сколько страниц вообще попадёт в индекс.
• Конверсию. Это не про SEO, но про деньги. На проектах с формами заявок каждая убранная секунда стабильно добавляла к конверсии несколько процентов.

Чего скорость не даёт:

• Роста по конкурентным коммерческим запросам сама по себе. Если у вас нет посадочной страницы под запрос, нет цен, нет отзывов и нет ссылок — сайт будет очень быстро находиться на 40-й позиции.
• Зелёных цифр в PageSpeed как самоцели. Я видел сайты с оценкой 98/100, которые не получали из поиска ничего, и сайты с 62/100 в устойчивом топ-3. Яндекс смотрит на реальные тайминги живых пользователей, а не на синтетический балл.

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

Если трафика мало не только из-за скорости

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

Я — частный SEO-специалист, работаю с клиентами напрямую, без менеджеров и аккаунтов посередине. За плечами больше 300 проектов, часть сайтов держится в ТОП-1 Яндекса восьмой год подряд. Веду каждый проект лично: сам делаю аудит, сам собираю семантику, сам отвечаю на ваши вопросы по телефону. В работе учитываю все основные факторы ранжирования — на сегодня их 1922 — и использую только белые методы, без накруток и фильтров.

Что предлагаю:

• SEO-продвижение сайта — от 55 000 ₽/мес. Технический аудит, семантическое ядро, оптимизация посадочных страниц, контент, ссылки, еженедельный отчёт с позициями. Цель не «улучшить видимость», а звонки и заявки.
• GEO-продвижение — оптимизация под YandexGPT, GigaChat, ChatGPT и Perplexity. Люди всё чаще спрашивают у нейросетей «кому заказать» вместо похода в поиск, и в этих ответах должны звучать вы, а не конкурент. Направление молодое, конкуренция в нём пока минимальна — заходить в него выгоднее сейчас, чем через год.
• SEO-аудит по 120+ параметрам — если нужен не подряд, а разбор: что чинить, в каком порядке и что это даст.

Начать можно бесплатно и без обязательств: запустите экспресс-аудит сайта — сервис за 30 секунд покажет технические ошибки, которые мешают продвижению, и оценит шансы выйти в ТОП по вашему ключевому запросу. Если после отчёта останутся вопросы — напишите мне или звоните напрямую: +7 (921) 333-77-45. Отвечу лично, скажу честно, есть ли смысл вкладываться в продвижение вашего сайта и за какой срок он окупится. И, кстати, попросите телефон любого моего действующего клиента — позвоните и спросите про результат сами.

Автор: Анатолий Кузнецов, частный SEO-специалист. Обо мне и о подходе к работе.