Чтобы получить зелёный PageSpeed на WordPress, нужно решить три независимые задачи: ускорить загрузку главного изображения (LCP), устранить визуальные сдвиги (CLS) и снизить время отклика на действия пользователя (INP). Каждый из этих показателей имеет пороговые значения и отдельный набор причин - и ни один плагин кэширования не закрывает все три одновременно.
Большинство русскоязычных гайдов по оптимизации WordPress написаны до марта 2024 года. Именно тогда Google заменил FID (First Input Delay) на INP (Interaction to Next Paint) в составе Core Web Vitals - и это не просто смена названия. FID измерял время до первого события, INP измеряет задержку любого взаимодействия на протяжении всей сессии. Плагины, которые оптимизировали FID через passive: true у event listeners, не улучшают INP ни на миллисекунду. Тем не менее большинство гайдов продолжают советовать «оптимизировать FID» - метрику, которой больше не существует в Google Search Console.
В проектах по оптимизации WordPress мы регулярно видим одну и ту же картину: сайт с установленными WP Rocket, Imagify и CloudFlare получает LCP около 2.8 секунды и INP 380 миллисекунд. LCP можно довести до нормы плагинами, INP - нет, потому что его корень в тяжёлых скриптах Elementor и сторонних виджетов, а не в кэшировании. Эта статья разбирает все три метрики по отдельности: причины, конкретные исправления и что реально влияет на каждую.
Как измерить правильно
Первая ошибка при оптимизации - ориентироваться только на Lighthouse. CrUX (Chrome User Experience Report) - это полевые данные реальных пользователей Chrome, которые Google использует для ранжирования. Lighthouse - это лабораторные данные: синтетический тест в управляемых условиях, который может не совпадать с реальным опытом пользователей.
PageSpeed Insights показывает оба источника одновременно. Зелёный Lighthouse при красном CrUX означает, что ваши реальные пользователи видят медленный сайт - и именно это влияет на позиции. Красный Lighthouse при зелёном CrUX - ваши пользователи довольны, оптимизировать нужно лишь отдельные сценарии.
Для мониторинга используйте Google Search Console раздел «Core Web Vitals» - там агрегированные данные CrUX по всем URL. PageSpeed Insights даёт данные по конкретной странице. Lighthouse в DevTools - для отладки в процессе работы.
Пороговые значения по состоянию на Q2 2026:
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | < 2.5 с | 2.5 - 4 с | > 4 с |
| CLS | < 0.1 | 0.1 - 0.25 | > 0.25 |
| INP | < 200 мс | 200 - 500 мс | > 500 мс |
LCP на WordPress - причины и исправления
LCP (Largest Contentful Paint) - время до отрисовки самого крупного элемента в области видимости, обычно hero-изображения или заголовка H1. Пороговое значение: менее 2.5 секунды для оценки «хорошо».
Основные причины плохого LCP на WordPress:
Неоптимизированное hero-изображение. WordPress загружает изображения по умолчанию в формате JPEG или PNG без WebP-конвертации. Изображение 1200x630 px весом 800 КБ отложит LCP на 1.5-2 секунды даже при нормальном хостинге.
Отсутствие preload для LCP-изображения. Браузер обнаруживает hero-изображение только при разборе HTML или CSS - это создаёт задержку. Тег <link rel="preload"> сообщает браузеру загрузить изображение сразу.
Медленный TTFB (Time to First Byte). Если сервер отдаёт первый байт через 1.2 секунды, LCP никак не может быть меньше 1.2 секунды. Виновники: общий хостинг без кэша, отсутствие object cache (Redis/Memcached), тяжёлые PHP-запросы без кэширования.
Блокирующие скрипты и шрифты. Google Fonts без display=swap и скрипты без defer или async блокируют рендеринг до завершения загрузки.
Что конкретно помогает:
- Конвертировать hero-изображение в WebP и задать атрибуты
widthиheight - Добавить
<link rel="preload" as="image" href="hero.webp">в<head> - Перейти на хостинг с LiteSpeed или Nginx + Redis (Kinsta, WP Engine, Cloudways)
- Подключить CDN (Cloudflare, BunnyCDN) для раздачи статики из ближайшей точки
- Загрузить шрифты локально вместо Google Fonts или добавить
&display=swapв URL
CLS на WordPress - причины и исправления
CLS (Cumulative Layout Shift) - суммарный сдвиг элементов во время загрузки страницы. Если кнопка «Купить» прыгает вниз в момент когда вы тянетесь к ней - это CLS. Пороговое значение: менее 0.1 для оценки «хорошо».
Основные причины плохого CLS на WordPress:
Изображения без атрибутов width и height. Браузер не резервирует место под изображение до его загрузки, поэтому при появлении картинки всё содержимое ниже сдвигается. Это самая частая причина высокого CLS на сайтах WordPress с пользовательским контентом.
FOUT (Flash of Unstyled Text). Веб-шрифты загружаются асинхронно, и пока они грузятся, браузер показывает системный шрифт. Когда шрифт загружается, текст перерисовывается - размер блоков меняется, элементы прыгают.
Рекламные блоки и виджеты без зарезервированного места. Баннеры, встроенные виджеты чата, pop-up формы - если для них не задан фиксированный размер контейнера, они вызывают сдвиг при инициализации.
Динамически вставляемый контент. Уведомления о cookie, floating CTA, sticky headers, которые появляются через JavaScript после загрузки страницы.
Что конкретно помогает:
- Всегда указывать
widthиheightу тегов<img>- это позволяет браузеру вычислить соотношение сторон до загрузки - Добавить
font-display: swapв CSS для всех веб-шрифтов (или использоватьfont-display: optionalдля некритичных шрифтов) - Задать минимальную высоту контейнера для рекламных блоков через CSS
- Для WordPress: в настройках Gutenberg и Elementor проверять, что все блоки изображений имеют заданные размеры
INP на WordPress - причины и исправления
INP (Interaction to Next Paint) - время от взаимодействия пользователя до визуального отклика страницы. Метрика заменила FID в марте 2024 года. Пороговое значение: менее 200 миллисекунд для оценки «хорошо».
Ключевое отличие от FID: INP измеряет задержку при любом клике, тапе или нажатии клавиши на протяжении всей сессии, и берёт 98-й процентиль - то есть худшие 2% взаимодействий. Страница может иметь отличный FID (быстрая реакция на первый клик) и при этом плохой INP (медленные отклики при последующих кликах, когда в main thread уже занят скриптами).
Основные причины плохого INP на WordPress:
Тяжёлые page builders. Elementor и Divi генерируют сотни килобайт JavaScript, который парсируется и выполняется в main thread. Каждый клик по элементу на странице соревнуется с этими скриптами за время процессора.
Аналитика и трекинг. Google Tag Manager с 15+ тегами, Hotjar, полный пакет Meta Pixel с Advanced Matching - все они запускают обработчики событий и блокируют main thread при взаимодействии пользователя со страницей.
Виджеты чата и поддержки. Intercom, Drift, HubSpot Chat - каждый из них добавляет 100-300 КБ JavaScript. При клике на страницу виджет перехватывает событие и обрабатывает его до того, как браузер успевает отрисовать ответ.
Плагины слайдеров и анимаций. Revolution Slider, Elementor Pro анимации, GSAP без lazy load - всё это скрипты, которые слушают события scroll и click и создают задержки.
Что конкретно помогает:
- Перенести загрузку всех некритичных скриптов на
deferилиasync(GTM, аналитика, чат-виджеты) - Аудит скриптов: в Chrome DevTools вкладка Performance записать сессию и найти Long Tasks (задачи длиннее 50 мс) - они прямые причины плохого INP
- Заменить Elementor/Divi на более лёгкие альтернативы или на блочный редактор Gutenberg
- Для чат-виджетов: загружать скрипт только при клике на кнопку чата, а не при загрузке страницы
- Убрать неиспользуемые плагины - даже деактивированные плагины иногда оставляют скрипты
Как найти проблемные скрипты через Chrome DevTools
Откройте DevTools (F12) -> Performance -> Record. Кликните по элементам страницы несколько раз, остановите запись. В треке «Main» найдите красные блоки - это Long Tasks. Нажмите на блок и посмотрите стек вызовов в нижней части: там будет виден конкретный скрипт.
В разделе «Bottom-Up» отсортируйте по «Total Time» - скрипты наверху списка тратят больше всего времени процессора.
Инфраструктура - что реально работает
Правильный выбор инфраструктуры решает LCP и TTFB, но не поможет с INP. Это важно понимать, чтобы не тратить бюджет на хостинг, надеясь исправить проблему скриптов.
CDN улучшает LCP. Раздача статических файлов (изображения, CSS, JS) с серверов ближе к пользователю снижает время загрузки на 200-500 мс для аудитории далеко от хостинга. Cloudflare бесплатный план закрывает базовые потребности, BunnyCDN - экономичная альтернатива для платного CDN.
Object cache улучшает TTFB. Redis или Memcached кэшируют результаты запросов к базе данных WordPress. Без object cache каждый запрос к странице генерирует десятки SQL-запросов. С Redis - один запрос к кэшу. На managed-хостингах (Kinsta, WP Engine, Cloudways) Redis подключается в два клика.
Managed хостинг против shared. На shared-хостинге соседи по серверу влияют на ваши TTFB. Managed WordPress хостинг (Kinsta, WP Engine, Cloudways) изолирует ресурсы и настроен специально под WordPress. Разница в TTFB - от 1.2 секунды до 200 миллисекунд на одном и том же сайте.
Плагины кэширования и INP. WP Rocket, LiteSpeed Cache, W3 Total Cache - все они улучшают LCP и CLS через правильную оптимизацию HTML/CSS/изображений, но не влияют на INP. INP - это задержка скриптов в браузере, а не скорость сервера.
Типичная ошибка: установить WP Rocket, получить LCP 2.3 секунды, считать сайт оптимизированным - и не заметить INP 420 миллисекунд, который остаётся в красной зоне.
Реальный кейс
Компания с WordPress-сайтом на shared-хостинге: PageSpeed 41, LCP 4.8 секунды, INP 450 миллисекунд, CLS 0.18. В Google Search Console около 80% URL в статусе «Требует улучшения» по CWV.
Что было сделано:
- Перевели hero-изображение в WebP, добавили
preload, задалиwidthиheightвсем изображениям - Перенесли Elementor на Gutenberg для основных страниц (landing, about, services)
- Настроили defer для GTM, Hotjar и чат-виджета Intercom (загрузка по клику)
- Переехали на Cloudways с Redis object cache и подключили Cloudflare CDN
- Добавили
font-display: swapдля Google Fonts, перенесли шрифты на локальный сервер
Результат через 6 недель (данные CrUX, не Lighthouse):
- PageSpeed: 41 -> 84
- LCP: 4.8 с -> 2.1 с (было «Плохо», стало «Хорошо»)
- INP: 450 мс -> 180 мс (было «Плохо», стало «Хорошо»)
- CLS: 0.18 -> 0.06 (было «Требует улучшения», стало «Хорошо»)
Ключевой вывод: 60% прироста по INP дало не изменение хостинга, а замена Elementor на Gutenberg и defer для сторонних скриптов.
Когда оптимизации WordPress недостаточно
Есть ситуации, когда проблема CWV структурная - и плагины её не решат.
WordPress с тяжёлым page builder (Elementor Pro, Divi, WPBakery) генерирует 400-800 КБ JavaScript на каждую страницу. Это не ошибка конфигурации - это архитектурное ограничение инструментов, которые работают через DOM-манипуляции в браузере. INP на таких сайтах стабильно выше 300 мс, даже при хорошем хостинге и CDN.
Если сайт собирается из 20+ плагинов, каждый из которых добавляет свои скрипты - суммарный вес JavaScript превысит 1 МБ. Оптимизировать это поштучно технически возможно, но дороже, чем пересмотреть архитектуру.
В таких случаях миграция на современный стек - Astro, Next.js с headless CMS - решает проблему CWV структурно. Astro по умолчанию отправляет в браузер нулевой JavaScript для статических страниц. Next.js с правильной конфигурацией даёт LCP меньше 1.5 секунды и INP меньше 100 мс без специальной оптимизации.
Если вы оцениваете такой переход - посмотрите на услугу миграции сайта: мы переносим WordPress-сайты на Astro с сохранением URL-структуры, контента и SEO-позиций. После миграции типовой маркетинговый сайт получает PageSpeed 90+ без дополнительной оптимизации.
Для сайтов, где WordPress остаётся и нужна постоянная работа с производительностью - есть поддержка и обслуживание сайта, включая мониторинг CWV и реакцию на просадки.
Часто задаваемые вопросы
Почему Lighthouse показывает 90+, а в Google Search Console - «Требует улучшения»?
Lighthouse - это лабораторный тест в контролируемых условиях: фиксированная скорость соединения, один тип устройства, один момент времени. Google Search Console отображает данные CrUX - агрегированные показатели реальных пользователей Chrome за последние 28 дней. Реальные пользователи приходят с разных устройств, соединений и географий. Lighthouse может быть зелёным, если ваш сервер быстро отвечает на один запрос - но реальные мобильные пользователи на 3G с Elementor получат INP 500 мс. Для ранжирования Google использует CrUX, не Lighthouse.
Какой плагин лучше всего улучшает Core Web Vitals на WordPress?
Одного универсального плагина не существует, потому что три метрики имеют разные причины. LCP и CLS хорошо улучшает WP Rocket или LiteSpeed Cache: они оптимизируют изображения, кэшируют HTML, управляют загрузкой CSS. INP они не улучшают - для этого нужно отдельно работать со сторонними скриптами и page builder. Реальный прирост по INP даёт не плагин, а аудит скриптов и отказ от тяжёлых инструментов типа Elementor.
Что такое INP и чем он отличается от FID?
INP (Interaction to Next Paint) - метрика, которая измеряет задержку отклика страницы на любое взаимодействие пользователя: клик, тап, нажатие клавиши. FID (First Input Delay) измерял задержку только первого взаимодействия. Google заменил FID на INP в марте 2024 года, потому что FID не отражал реальный опыт: страница могла быть быстрой при первом клике и тормозить при всех последующих. INP берёт 98-й процентиль всех взаимодействий за сессию - то есть выявляет худшие случаи, а не только первое событие.
Сколько времени занимает улучшение Core Web Vitals на реальном WordPress-сайте?
Зависит от масштаба проблем. Базовая оптимизация (WebP, preload, объектный кэш, CDN) выполняется за 1-2 дня и даёт прирост LCP и CLS. Работа с INP сложнее: аудит скриптов, замена page builder или настройка defer займут 1-2 недели на типовом сайте. Изменения в CrUX видны через 28 дней после деплоя - Google обновляет данные раз в неделю на основе скользящего окна. Рассчитывайте увидеть финальный результат в Search Console через 4-6 недель после внесения изменений.
Как проверить, какой элемент является LCP на конкретной странице?
Откройте Chrome DevTools -> Lighthouse -> запустите анализ производительности. В отчёте будет раздел «Largest Contentful Paint element» с указанием конкретного элемента. Альтернативно: в DevTools вкладка Performance -> запись загрузки страницы -> на треке «Timings» найдите маркер LCP и кликните на него - в нижней части экрана увидите элемент и его размер. Чаще всего это hero-изображение или крупный блок текста выше линии сгиба.
Если ваш WordPress-сайт застрял в красной зоне CWV и стандартные плагины не дают нужного результата - опишите задачу команде Exceltic.dev. Разберём конкретные причины просадки и предложим план: от точечной оптимизации до оценки целесообразности миграции на современный стек.