На прошлой неделе клиент скинул скриншот: страница услуг грузится 4,2 секунды по PageSpeed, LCP — 3,8 с, в Метрике видно, как посетители сваливаются ещё до того, как прогрузился первый экран. Вопрос был предсказуемый: «Надо переезжать на VPS за десять тысяч в месяц?» Не надо. Через два вечера работы без смены хостинга та же страница стала открываться за 1,3 секунды. В этой статье разбираю, что именно тормозило сайт, в каком порядке я это чинил и почему самая популярная рекомендация «поставь плагин кэша» сама по себе почти ничего не решает.
Что было за сайт
Классическая сборка: WordPress 6.x, тема с Elementor, 28 плагинов, виртуальный хостинг за 400 рублей в месяц. Посещаемость — около 8 тысяч визитов в месяц, обычный коммерческий сайт с формами заявок. Никакого высокого бюджета, никакого выделенного сервера — то, с чем я сталкиваюсь в девяти случаях из десяти.
Важный момент: я знал, что медленно, ещё до PageSpeed. Клиент жаловался на «тугое» админку и то, что мобильные посетители «как-то быстро уходят». Замеры только подтвердили ощущения.
Диагностика: сначала измерить, потом чинить
Первое правило, которое я выработал за годы поддержки сайтов: не чинить производительность вслепую. Порядок такой:
- PageSpeed Insights + полевые данные CRUX — смотрю LCP, INP, CLS по реальным пользователям, а не только по лабораторному тесту.
- Водопад сети в DevTools — что реально грузится, сколько запросов, что блокирует рендер.
- Query Monitor на самом сайте — сколько запросов к базе генерирует каждая страница и какие плагины их плодят.
Водопад показал гадость типичную для Elementor-сборок: 67 запросов на главной, из них 23 — CSS-файлы плагинов, которые подключены на каждой странице, хотя реально используются на двух. Ещё 1,9 секунды уходило на то, что я называю «парадом слайдеров»: три карусели инициализировались сразу, до взаимодействия с пользователем.
На что я смотрю в водопаде в первую очередь. Первое — полосы, которые начинаются поздно: если CSS третьего плагина стартует на отметке 1,2 с, проблема не в нём самом, а в том, что перед ним блокирует рендер чужой <link rel="stylesheet"> в <head>. Второе — «лесенка» из десятков мелких запросов к одному домену: это обычно иконочные шрифты и спрайты, разнесённые по отдельным файлам, и они дешевле всего объединяются. Третье — всё, что уходит на внешние домены: виджеты отзывов, чаты, пиксели. Каждый такой домен — это DNS + TCP + TLS до того, как запросится хоть один байт полезных данных, и на мобильной сети это легко съедает полсекунды на каждый.
Query Monitor добил картину: 86 запросов к базе на главной при нулевой посещаемости в момент замера. Для сравнения — нормально собранная тема на той же инсталляции делает 25–35. Разница почти целиком — плагины, которые «просто стоят», но на каждой загрузке страницы проверяют свои опции, свои лицензии и свои условия отображения виджетов.
Что я сделал — по шагам и по эффекту
1. Отключил неиспользуемый CSS и JS (эффект: −1,4 с)
Это самая большая победа. Плагинные стили подключались глобально — Contact Form 7 грузил свои ассеты на всех страницах, слайдер — тоже, виджет отзывов — ещё и свой внешний шрифт. Настроил выгрузку ассетов по условиям: форма — только там, где есть форма, слайдер — только на странице с слайдером. Если ваш стек собран вручную, ту же логику проще всего реализовать на уровне шаблона через wp_dequeue_script() и wp_dequeue_style() с проверкой условий. Тем, кто собирает окружение самостоятельно, будет полезен разбор Docker-стека для WordPress — там я показываю, как выстроить кэширование и сжатие на уровне Nginx, чтобы приложение вообще не трогало статику.
2. Перевёл изображения в WebP и lazy-load ниже первого экрана (эффект: −0,8 с)
Главный баннер весил 2,4 МБ в PNG. Пережал в WebP с качеством 82 — стал 280 КБ без видимой разницы. Всё, что ниже первого экрана, получило loading="lazy", а LCP-изображение, наоборот, — fetchpriority="high". Это бесплатные полсекунды, которые почему-то упорно игнорируют: ленивую загрузку ставят на всё подряд, включая главный баннер, и удивляются плохому LCP.
3. Кэширование + сжатие (эффект: −0,5 с)
Серверный кэш страниц, gzip/brotli для текста, кэш браузера для статики с заголовками на год. Здесь лабораторный тест перестал иметь большое значение — важно стало полевое время ответа сервера: TTFB упал с 680 мс до 190 мс.
4. Очистка плагинов (эффект: −0,2 с, но косвенно больше)
Из 28 плагинов 6 оказались мёртвыми: два не обновлялись больше двух лет, один вообще дублировал функции темы. Удалил. Query Monitor после чистки показал снижение числа запросов к базе с 86 до 41 на главной. Заодно это снизило поверхность для уязвимостей — об этом я подробно писал в материале про SEO 2026: поисковики всё честнее показывают в выдаче то, что реально быстро и удобно, а медленный сайт теряет даже те клики, которые ещё остались.
5. INP и CLS: метрики, которые чинятся не кэшем (эффект: INP −250 мс, CLS −0,16)
После трёх основных шагов LCP был уже нормальным, но INP оставался за 400 мс. Виновник нашёлся через долгие задачи в Performance-профиле: виджет отзывов пересчитывал раскладку на каждом скролле, и главная нить блокировалась кусками по 200–300 мс. Лечится это не «ещё одним плагином оптимизации», а банальным переносом работы в requestIdleCallback или отложенной инициализацией: слайдер и отзывы на этом сайте вообще не нужны до первого взаимодействия.
CLS в 0,18 был собран из трёх источников: баннер без явных width/height (прыжок на 0,09), поздно подгружающийся шрифт (ещё 0,05) и баннер согласия на куки, вставляющийся над шапкой (0,04). Первое лечится атрибутами размеров на каждом <img>, второе — font-display: swap и предзагрузкой основного начертания, третье — резервированием места под баннер до его отрисовки. Скучная работа, но именно она отличает сайт с «зелёным» CLS от сайта, который дёргается у пользователя перед глазами.
Что я сознательно не делал
Для честности — три вещи, которые советуют в половине гайдов, а я пропустил:
- Не объединял CSS и JS в один файл. В эпоху HTTP/2 и HTTP/3 это почти бесполезно, а вот кэширование пострадает: любое изменение одного стиля инвалидирует весь комбайн.
- Не ставил AMP. Для коммерческого сайта с формами это обычно отдельная головная боль с аналитикой и дублями страниц, а выигрыш по скорости сегодня достижим и без него.
- Не переезжал на VPS. При 8 тысячах визитов в месяц текущий хостинг после настройки кэша имеет запас по CPU в несколько раз. Переезд имеет смысл, когда упёрся в железо, а не в плохой код.
Итоговые цифры
| Метрика | До | После |
|---|---|---|
| LCP (мобильный) | 3,8 с | 1,3 с |
| INP | 410 мс | 160 мс |
| CLS | 0,18 | 0,02 |
| Запросов на главной | 67 | 31 |
| Запросов к базе | 86 | 41 |
| Вес главной | 6,1 МБ | 1,4 МБ |
Бюджет: ноль рублей на инфраструктуру, два вечера работы. Клиент через месяц отметил, что отказы из мобильного трафика снизились, а средняя глубина просмотра выросла примерно на четверть. Прямой причинно-следственной связи я здесь не обещаю — осень, сезон — но направление очевидное.
Отдельно отмечу: цифры выше — это не разовый «замер после оптимизации», а устоявшиеся значения спустя три недели наблюдения. Самое важное, что я сделал после публикации изменений, — поставил регулярный контроль: раз в неделю автоматический замер PageSpeed на трёх ключевых страницах с записью результатов в таблицу. Без этого любая установка очередного плагина через два месяца тихо откатывает всё назад, и никто этого не замечает до следующей жалобы клиента. Оптимизация скорости — это не разовое действие, а режим поддержки: та же логика, что и с обновлениями и бэкапами.
Мой субъективный вывод
Многие в этой ситуации начинают с премиум-хостинга, CDN и микрооптимизаций вроде «объедини CSS в один файл». По моему опыту, это лечение симптомов. Восемь из десяти медленных WordPress-сайтов страдают от одного и того же: неиспользуемые ассеты плагинов, непережатые изображения и десятки лишних запросов к базе. Пока это не вычистить, ни CDN, ни выделенный сервер кардинально ничего не изменят — разгонят доставку того же мусора.
И ещё одно: не доверяйте лабораторному PageSpeed больше, чем полевым данным. Лаборатория показывает одну загрузку на одном устройстве, а CRUX — тысячи реальных. Если они расходятся, оптимизируйте под реальных пользователей.
Чек-лист для самопроверки
- Снял водопад сети и нашёл ассеты, которые грузятся на всех страницах, но нужны не везде.
- Пережал изображения в WebP, LCP-картинке дал
fetchpriority="high", остальному —loading="lazy". - Проверил TTFB: больше 300 мс — сначала чинить серверный кэш, потом всё остальное.
- Посчитал запросы к базе через Query Monitor и нашёл виновных среди плагинов.
- Удалил плагины, которые не обновлялись больше года и не используются.
- Сравнил лабораторные метрики с полевыми CRUX и оптимизировал под вторые.
Скорость сайта — та редкая область, где маленький бюджет и два вечера дают измеримый результат. А у вас как: замеряли реальные полевые метрики или ориентируетесь на лабораторный PageSpeed? Интересно сравнить подходы.
