Core Web Vitals простыми словами: LCP, INP и CLS (и как их улучшить)

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

Три Core Web Vitals

Страница проходит оценку, когда не менее 75% реальных посещений (75-й процентиль) укладываются в порог «хорошо» по всем трём метрикам.

В марте 2024 года INP заменил First Input Delay (FID) в составе Core Web Vitals. INP строже: он учитывает отзывчивость взаимодействий на протяжении всего посещения, а не только первого.

Полевые и лабораторные данные

Полевые данные поступают от реальных пользователей Chrome и собираются в Chrome UX Report (CrUX) за скользящий 28-дневный период. Именно их Google использует для оценки удобства страницы. Их можно увидеть в отчёте Core Web Vitals в Search Console и в PageSpeed Insights.

Лабораторные данные — результат симулированного теста, например Lighthouse, на фиксированном устройстве и сети. Они отлично подходят для отладки и проверки изменений, но Google не использует их для ранжирования — и они не могут напрямую измерить INP (ближайший лабораторный аналог — Total Blocking Time).

У страниц с небольшим трафиком может не хватать полевых данных; в этом случае Google может использовать данные похожих страниц или всего сайта («источника»).

Largest Contentful Paint (LCP)

LCP отмечает момент, когда завершается отрисовка самого крупного изображения или текстового блока в видимой области, — обычно это главное изображение, крупный заголовок или обложка видео.

LCP можно разложить на четыре части, которые подсказывают, что исправлять:

1. Time to First Byte — сколько времени нужно серверу, чтобы ответить
2. Задержка загрузки ресурса — сколько проходит времени, прежде чем браузер начнёт скачивать ресурс LCP
3. Время загрузки ресурса — сколько длится скачивание
4. Задержка отрисовки элемента — время между скачиванием и отрисовкой

Как улучшить LCP

• Ускорьте сервер: кэширование страниц, CDN, более быстрый хостинг и меньше запросов к базе данных
• Сделайте изображение LCP заметным как можно раньше: используйте обычный <img> в HTML (а не CSS-фон или изображение, вставленное через JavaScript) и добавьте fetchpriority="high"
• Никогда не применяйте lazy loading к изображению LCP
• Оптимизируйте изображение: правильные размеры, WebP или AVIF, хорошее сжатие
• Сократите ресурсы, блокирующие отрисовку: встраивайте критический CSS, откладывайте некритичный JavaScript
• Используйте preconnect к нужным сторонним источникам, например к CDN изображений

Interaction to Next Paint (INP)

INP измеряет задержку между действием пользователя — кликом, касанием или нажатием клавиши — и следующим визуальным обновлением на экране. Он отражает одно из самых медленных взаимодействий за посещение.

Плохой INP обычно связан с избытком JavaScript в основном потоке, из-за которого браузер не может быстро отреагировать.

Как улучшить INP

• Сократите и разделите JavaScript: уберите неиспользуемые библиотеки, разбейте код на части и загружайте функции только тогда, когда они нужны
• Разбивайте длинные задачи: задачи дольше 50 мс блокируют основной поток; возвращайте управление браузеру между порциями работы
• Проверьте сторонние скрипты: менеджеры тегов, виджеты чатов, инструменты A/B-тестирования и рекламные скрипты — частые виновники
• Держите DOM компактным: на очень больших страницах каждое обновление идёт медленнее
• Давайте мгновенную визуальную реакцию на действие, а тяжёлую работу выполняйте после

Cumulative Layout Shift (CLS)

CLS измеряет неожиданные сдвиги макета — то раздражающее ощущение, когда кнопка отпрыгивает в момент нажатия. Метрика учитывает, сколько контента сдвигается и на какое расстояние.

Как улучшить CLS

• Указывайте ширину и высоту изображений и видео или используйте CSS-свойство aspect-ratio, чтобы место резервировалось заранее
• Резервируйте место под рекламу, встраиваемые элементы и iframe с помощью контейнеров фиксированного размера
• Не вставляйте контент над уже показанным, например баннеры, которые сдвигают страницу вниз после загрузки
• Осторожно используйте font-display: swap и предзагружайте ключевые веб-шрифты либо используйте метрики запасных шрифтов, чтобы текст не перестраивался
• Анимируйте через transform, а не через свойства вроде top или height, которые вызывают перерасчёт макета

Практический порядок работы

1. Проверьте отчёт Core Web Vitals в Search Console, чтобы увидеть, какие группы URL не проходят оценку и по какой метрике
2. Выберите показательный URL из каждой проблемной группы
3. Запустите лабораторный тест, чтобы найти, что именно медленно
4. Исправляйте на уровне шаблона — большинство проблем затрагивают все страницы с одинаковым макетом
5. Подтвердите исправление: в Search Console запустите проверку после выкладки; полевым данным нужно до 28 дней, чтобы отразить улучшения

Насколько Core Web Vitals влияют на позиции?

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

Советы для разных платформ

WordPress

• Используйте плагин кэширования или кэширование на уровне хостинга, чтобы сократить время ответа сервера
• Выбирайте лёгкую тему; тяжёлые конструкторы страниц часто добавляют много CSS и JavaScript
• Проверьте плагины: каждый может добавлять скрипты на все страницы и ухудшать INP
• Используйте плагин оптимизации изображений, который отдаёт WebP или AVIF и добавляет атрибуты ширины и высоты
• Отложите или уберите сторонние скрипты, которые не нужны на каждой странице

Shopify

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

Самописные сайты и сайты на JavaScript

• Используйте серверный рендеринг или статическую генерацию, чтобы контент появлялся без ожидания JavaScript
• Разделяйте код по маршрутам и загружайте компоненты по требованию
• Измеряйте INP реальных пользователей с помощью JavaScript-библиотеки web-vitals и отправляйте данные в аналитику, чтобы видеть, какие взаимодействия медленные

Как самому измерять данные реальных пользователей

Search Console и PageSpeed Insights показывают агрегированные данные Chrome, но только для страниц с достаточным трафиком и с задержкой. Чтобы видеть Core Web Vitals для каждой страницы и каждого посетителя, добавьте мониторинг реальных пользователей (RUM). Библиотека с открытым кодом web-vitals собирает LCP, INP и CLS из браузеров посетителей; значения можно отправлять в Google Analytics 4 или другую систему аналитики. RUM также фиксирует, какой элемент был LCP и какое взаимодействие оказалось самым медленным, — ровно то, что нужно для исправления проблемы.

Пара слов о Total Blocking Time и Speed Index

Lighthouse показывает и другие метрики, кроме Core Web Vitals. Total Blocking Time (TBT) измеряет, как долго основной поток был заблокирован во время загрузки, и коррелирует с INP. First Contentful Paint (FCP) отмечает, когда появляется первый контент. Speed Index показывает, как быстро заполняется видимая область. Это полезная диагностика, но сами по себе они не входят в Core Web Vitals.

Распространённые мифы

• «Чтобы ранжироваться, нужен балл 100 в PageSpeed». Нет. Для удобства страницы важно проходить пороги Core Web Vitals по полевым данным, а релевантность значит намного больше.
• «Core Web Vitals важны только для Google». Более быстрые и стабильные страницы повышают конверсию и удовлетворённость каждого посетителя, откуда бы он ни пришёл.
• «Чем больше плагинов кэширования, тем лучше». Несколько плагинов кэширования или оптимизации одновременно часто конфликтуют. Используйте одно хорошо настроенное решение.

Главное

• Core Web Vitals измеряют загрузку (LCP), отзывчивость (INP) и визуальную стабильность (CLS).
• Хорошие пороги: LCP ≤ 2,5 с, INP ≤ 200 мс и CLS ≤ 0,1 на 75-м процентиле реальных посещений.
• Значение имеют полевые данные реальных пользователей Chrome; лабораторные тесты нужны для диагностики.
• LCP обычно улучшается благодаря более быстрому серверу и лучше оптимизированным главным изображениям.
• INP улучшается, когда вы сокращаете и разбиваете JavaScript, особенно сторонние скрипты.
• CLS улучшается, когда вы резервируете место для изображений, рекламы и встраиваемых элементов.

Часто задаваемые вопросы

Почему лабораторные и полевые оценки различаются?

Лабораторные тесты имитируют одно устройство и одну сеть. Полевые данные отражают устройства, сети и поведение ваших реальных посетителей, включая взаимодействия, которых лабораторные тесты не выполняют.

Через сколько улучшения появятся в Search Console?

Полевые данные охватывают предыдущие 28 дней, поэтому исправление полностью отразится в течение четырёх недель.

Важны ли Core Web Vitals на десктопе?

Да. Google оценивает мобильные устройства и десктоп отдельно. На мобильных пройти оценку обычно сложнее, потому что устройства и сети медленнее.

Какой балл PageSpeed считается хорошим?

90 и выше — хорошо. Но балл — это сводка лабораторного теста; для удобства страницы важно проходить Core Web Vitals по полевым данным.