Core Web Vitals — набор из трёх ключевых метрик пользовательского опыта, которые Google использует как фактор ранжирования. Они отражают, насколько быстро страница загружается, отзывчиво реагирует на ввод и стабильно отображается.
Три метрики: LCP (скорость отрисовки крупного элемента), CLS (сдвиг макета), INP (реакция на ввод). Измеряются по реальным пользователям через Chrome User Experience Report. Сильнее всего влияют на мобильные позиции и YMYL-тематики.
Как делать правильно
- тяжёлый JS, блокирующий рендер
- большие неоптимизированные картинки
- сдвиги при загрузке (баннеры, шрифты)
- медленные ответы сервера
- критичный CSS инлайн, остальное async
- WebP / AVIF + lazy loading
- размеры картинок указаны через width/height
- CDN + кеширование на серверной стороне
Эволюция
Интернет-магазин одежды: LCP 5,8 с, CLS 0,38, INP 480 мс — все три в «красной» зоне. Оптимизировали изображения в WebP, заинлайнили critical CSS, добавили width/height на все картинки, оптимизировали JS-обработчики. Через 2 месяца: LCP 1,9 с, CLS 0,06, INP 110 мс. Позиции +12% по мобильным запросам.
Главная ловушка — путать «полевые» (field) и «лабораторные» (lab) данные. PageSpeed Insights показывает и те и другие, но в ранжировании учитываются только полевые из CrUX: реальные сессии Chrome за последние 28 дней. Локальный тест в Lighthouse может выдать зелёный LCP 1,9 с, а у живых пользователей на 4G и бюджетных Android будет 4,5 с — Google смотрит на 75-й перцентиль, то есть метрика «зелёная» только когда у трёх четвертей визитов она в норме. Если трафика мало, CrUX по URL вообще нет, и оценка идёт по агрегату всего домена.
INP заменил FID в марте 2024 и стал самым болезненным порогом: FID мерил лишь задержку до первой реакции, а INP — все взаимодействия за сессию и время до следующей отрисовки. Тяжёлые обработчики на React/Vue, сторонние теги (чаты, аналитика, виджеты) и long tasks свыше 50 мс легко выбивают INP за 200 мс. У Яндекса прямого аналога Core Web Vitals нет, но скорость и стабильность он оценивает через свои поведенческие сигналы и данные Метрики, так что оптимизация полезна на обоих рынках, хотя формальный фактор ранжирования — только у Google.
Время до отрисовки самого крупного элемента экрана — обычно героя-картинки или H1; режут его critical CSS, приоритет загрузки и быстрый TTFB.
Задержка между действием пользователя и видимым откликом по всем кликам сессии; страдает от тяжёлого JS и сторонних виджетов.
Сумма неожиданных сдвигов макета при загрузке; убирается фиксацией размеров картинок, резервом под баннеры и font-display: optional.
Медиапортал держал LCP 2,1 с в Lighthouse и считал, что всё хорошо, но в Search Console отчёт Core Web Vitals помечал 60% мобильных URL как «требуют улучшения»: в CrUX 75-й перцентиль LCP был 3,8 с из-за рекламного скрипта, грузившего шрифт. Перенесли рекламу в async, добавили preload для LCP-картинки и font-display: swap — через 28 дней (окно обновления CrUX) доля «хороших» URL выросла с 28% до 8