Почему WordPress тормозит и как его ускорить

Медленный WordPress — это почти всегда сумма мелочей, а не одна поломка. Тема тянет три шрифта, слайдер на главной весит 4 мегабайта, кэша нет, база разрослась, а сервер отвечает за полсекунды ещё до того, как браузер получит первый байт. Разбирать это надо по слоям, снизу вверх, и обязательно с цифрами до и после.

Бюджет времени: сколько у вас есть

Ориентир задают Core Web Vitals — метрики, которые Google измеряет на реальных посетителях и учитывает в ранжировании:

LCP — главная цель, и внутри этих 2,5 секунды нужно уместить четыре этапа. Разумное распределение бюджета для WordPress с аудиторией в России выглядит так:

Смысл бюджета в том, что перерасход на одном этапе нельзя компенсировать другим. Если сервер отдал первый байт через 1,2 секунды, уложиться в норму уже невозможно: браузер физически не успеет собрать страницу за оставшиеся 1,3 секунды.

С чего начинается диагностика

Три инструмента, каждый отвечает на свой вопрос.

PageSpeed Insights (pagespeed.web.dev) — единственный источник полевых данных. Верхний блок «Оценка реального пользовательского опыта» показывает, что видят живые посетители за последние 28 дней. Именно эти цифры Google использует в ранжировании. Нижний блок с оценкой из ста баллов — лабораторный тест на эмулированном медленном телефоне, и относиться к нему нужно как к подсказке, а не как к цели. Гнаться за 100 баллами бессмысленно, а вот зелёный LCP в полевых данных — реальная задача.

WebPageTest (webpagetest.org) — детализация по этапам. Выбираете узел в нужном регионе, получаете водопад запросов: видно, сколько ждали сервер, когда пришёл HTML, какой файл заблокировал отрисовку. Строка Time to First Byte в отчёте — та самая цифра, вокруг которой строится половина оптимизации.

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

Порядок простой: сначала снимаете цифры, потом меняете что-то одно, потом снимаете снова. Замер после каждого шага — единственный способ понять, что сработало, а что было плацебо.

Полевые данные обновляются с задержкой: изменения на сайте появятся в отчёте PageSpeed Insights в течение нескольких недель, потому что метрика считается по скользящему окну в 28 дней. Лабораторные тесты реагируют сразу — по ним и сверяются в процессе работы.

Что делает хостинг, а что сайт

Полезно понимать, за что вы вообще можете взяться, а что определяется тарифом.

Из девяти провайдеров каталога объектный кэш на виртуальном хостинге заявлен у NetAngels, у SpaceWeb он появляется на тарифах от 1 199 ₽/мес. У остальных этот пункт на странице тарифов не указан — уточняйте до покупки, потому что для WooCommerce и сайтов с авторизацией это ключевая вещь. Полный разбор того, на что смотреть в тарифе, — в чек-листе выбора хостинга.

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

Три слоя кэша и зачем нужен каждый

Кэш в WordPress — не одна настройка, а три независимых механизма. Их часто путают, и потому ставят три плагина, которые делают одно и то же.

OPcache живёт в самом PHP. Он хранит скомпилированный байт-код скриптов, чтобы интерпретатор не разбирал одни и те же файлы при каждом запросе. WordPress с двадцатью плагинами подключает больше тысячи PHP-файлов на каждый хит, так что без OPcache сервер выполняет много бессмысленной работы. Включается на стороне хостинга, проверяется через Консоль → Информация о системе или phpinfo().

Объектный кэш (Redis или Memcached) хранит результаты запросов к базе в оперативной памяти. Одна страница WordPress делает от 30 до 200 запросов, и значительная часть из них повторяется от загрузки к загрузке: настройки, меню, метаданные. Объектный кэш особенно важен там, где страничный не работает — в админке, корзине, личном кабинете, то есть на всех страницах авторизованного пользователя.

Страничный кэш — самый мощный по эффекту. Он сохраняет готовый HTML и отдаёт его следующему посетителю без запуска PHP вообще. TTFB на закэшированной странице падает до величин, сравнимых с отдачей статического файла. Ограничение очевидно: динамические страницы так отдавать нельзя, поэтому корзина, оформление заказа и личный кабинет из кэша исключаются.

Что выбрать из плагинов:

• На LiteSpeed — только LiteSpeed Cache. Он работает на уровне веб-сервера, до запуска PHP, и умеет ESI-вставки: страница отдаётся из кэша, а живым остаётся один фрагмент вроде корзины.
• На Nginx или Apache — WP Super Cache для простого сайта, W3 Total Cache для сложного.
• Ставить два плагина кэша сразу нельзя. Оба кладут в wp-content свои advanced-cache.php и object-cache.php, перетирают друг друга и роняют сайт белым экраном.

После включения кэша проверьте, что он действительно работает: откройте страницу в режиме инкогнито, посмотрите заголовки ответа через curl -I вашсайт.ru. Плагины обычно добавляют заголовок вида x-litespeed-cache: hit или комментарий в конце HTML.

Изображения — самый тяжёлый слой

На типичном сайте картинки дают больше половины веса страницы, и это первое, за что стоит взяться на стороне контента.

Формат. WebP меньше JPEG примерно на четверть при той же видимой глубине качества, AVIF ещё компактнее, но требует свежего PHP-расширения на сервере. WordPress с версии 5.8 умеет работать с WebP из коробки, конвертацию медиатеки делают плагины вроде Imagify или Converter for Media.

Размеры. Классическая ошибка — фотография 4000 пикселей по ширине, вставленная в блок шириной 800. Браузер скачивает всё, а показывает уменьшенную копию. WordPress генерирует набор размеров автоматически и подставляет srcset, но только если исходник загружен разумного размера. Практическое правило: перед загрузкой уменьшайте до двукратной ширины блока, где картинка будет показана.

Отложенная загрузка. С WordPress 5.5 атрибут loading="lazy" проставляется автоматически. Важный нюанс: главное изображение первого экрана из ленивой загрузки надо исключить, иначе LCP ухудшится — браузер отложит загрузку именно того элемента, по которому метрика и считается. В плагинах оптимизации за это отвечает настройка вроде «исключить первые N изображений».

Размеры в разметке. У каждого <img> должны быть заданы width и height. Без них браузер не знает, сколько места резервировать, и вёрстка прыгает при загрузке — это прямой вклад в CLS.

База данных — невидимый тормоз

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

Автозагружаемые опции. Таблица wp_options содержит строки с флагом autoload = yes — они читаются при каждом запросе, включая запросы к API и админке. Нормальный объём — до 300–500 КБ. Плагины, особенно удалённые не полностью, оставляют там мусор, и объём вырастает до нескольких мегабайт, которые база читает миллионы раз в месяц. Посмотреть размер:

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

Список самых крупных записей:

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

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

Ревизии записей. Каждое сохранение статьи создаёт копию. У сайта с сотней статей и активным редактором это тысячи строк в wp_posts. Ограничить на будущее — константой в wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Просроченные транзиенты и спам. Транзиенты — временные данные плагинов, которые не всегда удаляются по расписанию. Плюс спам-комментарии, которые копятся годами. Чистится плагином вроде WP-Optimize или командами WP-CLI:

wp transient delete --expired
wp comment delete $(wp comment list --status=spam --format=ids) --force

Тип таблиц. Старые сайты иногда до сих пор живут на MyISAM, унаследованном от переездов десятилетней давности. InnoDB работает лучше на конкурентных запросах и не блокирует таблицу целиком при записи. Проверить: SHOW TABLE STATUS;, столбец Engine.

Плагины и тема

Здесь работает не подсчёт, а измерение. Тридцать простых плагинов могут стоить дешевле одного конструктора страниц.

Включите Query Monitor и откройте типичную страницу сайта. В панели внизу — вкладка «Queries by Component»: список компонентов с числом запросов и временем. Дальше вопрос на каждый: этот плагин стоит своих 40 запросов?

Что обычно всплывает в таких аудитах:

• Конструкторы страниц вроде Elementor и WPBakery — тянут собственный CSS и JS на каждую страницу, даже если конкретная страница собрана без них.
• Слайдеры на главной — почти всегда самый тяжёлый элемент первого экрана.
• Плагины «всё в одном» для SEO, безопасности и статистики — работают на каждом запросе, включая фронтенд.
• Внешние скрипты: чаты, пиксели, виджеты соцсетей. Они не влияют на TTFB, но съедают INP и блокируют главный поток браузера.
• Забытые плагины, которые ставили под разовую задачу два года назад.

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

Шрифты. Каждое семейство — это отдельная загрузка и потенциальная задержка отрисовки текста. Практика: не больше двух семейств, только нужные начертания, файлы на своём сервере, font-display: swap в CSS. Шрифты, подключённые с внешнего домена, добавляют DNS-запрос и установку соединения перед тем, как браузер вообще начнёт их скачивать.

Heartbeat API. WordPress каждые 15–60 секунд стучится в admin-ajax.php из открытой админки. При десятке одновременно работающих редакторов это заметная нагрузка на PHP. Регулируется плагином Heartbeat Control — интервал в 60 секунд достаточен для автосохранения.

Когда упираешься в хостинг

Признаки, что дальше оптимизировать сайт бесполезно:

• TTFB держится выше 500 мс при работающем страничном кэше — то есть сервер медленно отдаёт даже готовый HTML.
• В панели появляются предупреждения о превышении лимита CPU или числа процессов.
• Ошибки 502 и 503 в часы пик, а в остальное время сайт работает нормально.
• Админка ощутимо медленнее публичной части, и объектный кэш ситуацию не меняет.
• Поддержка на вопрос о нагрузке отвечает предложением «оптимизировать сайт» без конкретики.

Дальше выбор из трёх вариантов. Сменить тариф внутри того же провайдера — самое дешёвое, помогает, если упор в квоты, а не в саму площадку. Перейти на VPS — контроль над стеком и выделенные ресурсы, но настройка и обслуживание на вас. Взять managed-тариф — стек уже собран и обновляется провайдером, платите за то, что не занимаетесь сервером.

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

План на два часа

Порядок, отсортированный по отношению выигрыша к усилиям.

1. Замер до. PageSpeed Insights (мобильная версия) и WebPageTest, записать LCP, INP и TTFB. 10 минут.
2. PHP. Переключить на 8.2 или 8.3 в панели, проверив сайт на копии. 15 минут.
3. Страничный кэш. Один плагин под ваш веб-сервер, проверка через curl -I. 20 минут.
4. Изображения. Конвертация медиатеки в WebP, исключение первого экрана из lazy-load. 30 минут.
5. База. Автозагружаемые опции, ревизии, транзиенты, спам. 20 минут.
6. Плагины. Query Monitor, отключить два-три самых дорогих и ненужных. 30 минут.
7. Замер после. Те же инструменты, сравнить с исходными цифрами. 10 минут.

Если после этого LCP всё ещё за пределами 2,5 секунды, а TTFB не опускается ниже 500 мс — вы в ситуации, когда дальше решает не сайт, а сервер под ним.