Core Web Vitals — три метрики Google, которые измеряют скорость загрузки, отзывчивость на действия и визуальную стабильность страницы. Google использует их как сигнал ранжирования и показывает результат в Search Console и PageSpeed Insights. Разберём, какую часть метрик решает хостинг, а какую — тема и плагины WordPress.
Три метрики и их пороги
LCP (Largest Contentful Paint) измеряет время до отрисовки самого крупного видимого блока — обычно это главное изображение или заголовок. INP (Interaction to Next Paint) измеряет задержку между действием посетителя (клик, тап, нажатие клавиши) и обновлением экрана в ответ; эта метрика заменила FID в марте 2024 года. CLS (Cumulative Layout Shift) считает, насколько сильно элементы страницы сдвигаются после первой отрисовки.
| Метрика | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|
| LCP | до 2.5 c | от 2.5 до 4.0 c | более 4.0 c |
| INP | до 200 мс | от 200 до 500 мс | более 500 мс |
| CLS | до 0.1 | от 0.1 до 0.25 | более 0.25 |
Google считает страницу прошедшей Core Web Vitals, если минимум 75% визитов укладываются в порог «хорошо» — данные с мобильных и настольных устройств оцениваются отдельно, и сайт может проходить на десктопе и не проходить на мобильном.
Где смотреть реальные значения
PageSpeed Insights показывает два набора цифр: Lab Data — один замер в контролируемых условиях, и Field Data — агрегированные данные реальных посетителей за 28 дней (Chrome User Experience Report). Для оценки прохождения порога важен именно Field Data; Lab Data нужен для диагностики причины.
В Search Console раздел «Основные интернет-показатели» группирует страницы по реальным данным посетителей и показывает, какая метрика проваливает группу URL — это быстрее, чем проверять страницы по одной.
Что чинит хостинг: TTFB и сжатие
LCP напрямую зависит от того, как быстро сервер отдаёт первый байт HTML (TTFB) — чем позже браузер получит документ, тем позже начнётся загрузка главного изображения. Включённое сжатие ответов уменьшает размер HTML, CSS и JS, которые нужно скачать до начала отрисовки; подробная настройка разобрана в статье про Gzip и Brotli в Nginx.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/Если TTFB выше нескольких сотен миллисекунд уже на пустой странице без плагинов, проблема не в метриках, а в перегруженном тарифе или медленном диске — ни один плагин кэширования эту часть LCP не исправит.
Кэширование и CDN: когда помогают LCP, а когда нет
Кэш страницы и CDN ускоряют именно повторные визиты и статические файлы — картинки, шрифты, CSS. Подборка приёмов из практики ускорения WordPress:
- Включить кэш страниц и убедиться, что HTML-страница отдаётся из кэша, а не генерируется PHP при каждом визите.
- Отдавать изображения в современных форматах и правильного размера — крупное изображение, уменьшенное только CSS, всё равно загружается полным весом и тормозит LCP.
- Добавить preconnect к домену CDN и шрифтов, чтобы браузер открыл соединение заранее, а не в момент, когда до него дойдёт очередь.
- Отложить загрузку некритичного CSS и JS, которые не нужны для отрисовки первого экрана, но не трогать скрипты, которые формируют верхний блок страницы.
- Не кэшировать страницы с персональным содержимым (корзина, личный кабинет) целиком — это не ускорит LCP для них, а создаст показ чужих данных другому посетителю.
Эти приёмы разобраны подробнее в статье про ускорение WordPress; начинать стоит с них, а не с правки конкретной метрики вручную.
Что хостинг не может починить
INP почти всегда зависит от количества и веса JavaScript, который выполняется в браузере посетителя — тяжёлые конструкторы страниц, лишние виджеты и скрипты аналитики блокируют основной поток на время обработки клика. Хостинг не исполняет JS за посетителя и не может ускорить код темы или плагина.
CLS чаще всего портят изображения без заданных атрибутов width и height, веб-шрифты, которые подменяют текст после загрузки, и блоки рекламы, которые появляются с задержкой и сдвигают контент. Часть этого решает кэш статических ресурсов и правильная настройка кэширующего плагина — например, как это сделано в статье про LiteSpeed Cache для WordPress, — но исходную разметку темы всё равно нужно чинить на уровне кода.
Частые вопросы
Может ли хостинг гарантировать прохождение Core Web Vitals?
Нет, хостинг отвечает за TTFB, сжатие ответов и доступность кэша, но итоговые метрики складываются из кода темы, количества плагинов и их JavaScript — на одном и том же сервере один сайт проходит порог, а другой с тяжёлой темой нет.
Почему PageSpeed Insights показывает хороший LCP, а Search Console — плохой?
PageSpeed Insights в режиме Lab Data делает один замер в контролируемых условиях и часто на быстром соединении, а Search Console показывает Field Data за 28 дней с реальных устройств и сетей посетителей, включая медленный мобильный интернет — расхождение нормальное и означает, что нужно смотреть именно на Field Data.
Что делать, если CLS хороший в Lab Data, но плохой у реальных посетителей?
Проверить блоки, которые подгружаются с задержкой только у части посетителей — баннеры с согласием на cookie, виджеты чата, отложенная реклама — в контролируемом замере PageSpeed Insights они часто не успевают появиться и не портят показатель, а у реальных посетителей успевают.