Что означают LCP, INP и CLS?

Это три метрики Core Web Vitals, по которым Google оценивает пользовательский опыт страницы. Largest Contentful Paint (LCP) измеряет загрузку: за какое время появляется основное содержимое. Interaction to Next Paint (INP) измеряет отзывчивость: насколько быстро страница реагирует на клик, касание или ввод с клавиатуры. Cumulative Layout Shift (CLS) измеряет визуальную стабильность: насколько сильно «прыгает» макет. Хорошими считаются значения LCP не более 2.5 секунды, INP не более 200 миллисекунд и CLS не более 0.1.

Три метрики вкратце

Это пороговые значения из справки Google по отчёту Core Web Vitals. Страница считается пройденной, если все три метрики хорошие на 75-м процентиле визитов; мобильные устройства и десктоп оцениваются отдельно.

LCP: Largest Contentful Paint

LCP — это время от начала загрузки страницы до отрисовки самого большого изображения, видео или блока текста в видимой области. К подходящим элементам относятся <img>, изображения внутри SVG, постер или первый кадр видео, фоновые изображения CSS и блочный текст. Как только посетитель начинает взаимодействовать со страницей, браузер перестаёт искать новых кандидатов. Медленный LCP обычно вызван медленным ответом сервера, крупным или поздно обнаруженным главным изображением либо CSS и скриптами, блокирующими отрисовку.

INP: Interaction to Next Paint

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

CLS: Cumulative Layout Shift

CLS суммирует неожиданные сдвиги макета — например, когда текст съезжает вниз из-за загрузки изображения или рекламы над ним, — и показывает самую большую серию таких сдвигов за визит. Каждый сдвиг оценивается по тому, какая часть экрана сместилась и насколько далеко. Сдвиги в пределах 500 миллисекунд после клика, касания или нажатия клавиши не учитываются, поскольку в этот момент посетитель ожидает изменения страницы.

Откуда берутся эти значения?

Отчёт Core Web Vitals в Search Console использует полевые данные Chrome UX Report: реальные визиты в Chrome за последние 28 дней, сгруппированные по наборам похожих страниц; каждая группа оценивается по худшей из метрик. Лабораторные инструменты вроде Lighthouse загружают страницу без реального посетителя, поэтому не могут измерить INP и вместо него используют Total Blocking Time — об этом рассказывает обзор Web Vitals на web.dev. Лабораторные оценки полезны для отладки, а вердикт выносят полевые данные.

Влияют ли Core Web Vitals на ранжирование?

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

Чем помогает AutoPSEO

Отчёт Core Web Vitals в AutoPSEO читает историю Chrome UX Report для всего сайта или отдельного URL по телефонам, десктопам и планшетам и строит графики LCP, INP и CLS (а также first contentful paint и time to first byte) на 75-м процентиле по еженедельным данным примерно за шесть месяцев — так вы увидите, когда метрика начала ухудшаться.