Core Web Vitals простыми словами: LCP, INP и CLS

Core Web Vitals — не тест личности для вашего сайта

Core Web Vitals часто воспринимают как загадочную систему оценок. Страница получает красное число, кто-то публикует скриншот в Slack, и команда начинает спорить о JavaScript-фреймворках.

Это не особенно полезно.

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

• Основной контент появляется слишком долго.
• Страница медленно реагирует, когда пользователь пытается что-то сделать.
• Макет скачет, пока пользователь читает или нажимает.

Это и есть три Core Web Vitals: LCP, INP и CLS.

Google использует их как часть сигналов page experience, но SEO — не лучшая причина обращать на них внимание. Причина лучше — медленные, скачущие и неотзывчивые страницы тратят время пользователей. Они также обычно хуже конвертируют, хуже поддерживаются и быстрее устаревают.

Три метрики в одном предложении каждая

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

• LCP, или Largest Contentful Paint, измеряет, сколько времени нужно, чтобы загрузился основной видимый контент.
• INP, или Interaction to Next Paint, измеряет, насколько быстро страница отвечает на пользовательские взаимодействия в течение визита.
• CLS, или Cumulative Layout Shift, измеряет, насколько сильно страница неожиданно сдвигается.

Обычные пороговые значения такие:

| Метрика | Хорошо | Требует улучшения | Плохо | |---|---:|---:|---:| | LCP | 2.5s или быстрее | 2.5s–4.0s | Более 4.0s | | INP | 200ms или быстрее | 200ms–500ms | Более 500ms | | CLS | 0.1 или ниже | 0.1–0.25 | Более 0.25 |

Обычно эти числа оцениваются по 75-му процентилю реальных пользовательских визитов. Это важно. Ваша цель — не один идеальный лабораторный запуск. Ваша цель — хороший опыт для большинства пользователей, включая людей на более медленных телефонах и в менее стабильных сетях.

Если вы смотрите на автоматический отчёт и не понимаете, с чего начать, полезно отделить диагностику от паники. У нас есть отдельное руководство о том, как читать отчёт Lighthouse без паники, где этот процесс разобран подробнее.

LCP: когда страница ощущается загруженной?

Largest Contentful Paint измеряет время отрисовки самого крупного видимого элемента контента в области просмотра. На практике это часто:

• hero-изображение,
• крупный заголовок,
• изображение ведущей статьи,
• изображение товара,
• большой блок текста.

LCP не спрашивает, когда загрузились все скрипты, пиксели отслеживания и изображения ниже первого экрана. Он спрашивает: когда стало видно главное, ради чего пользователь пришёл на страницу?

Поэтому LCP — более человеческая метрика, чем старомодное «время загрузки страницы». Страница может технически завершить загрузку поздно, но всё равно ощущаться быстрой, если основной контент появляется быстро. Верно и обратное: страница может вызвать событие load, пока hero-блок всё ещё пустой, размытый или заблокирован задержкой рендеринга.

Частые причины плохого LCP

Большинство проблем с плохим LCP возникают в нескольких предсказуемых местах:

1. Медленный ответ сервера

Если HTML-документ приходит поздно, всё остальное тоже начинается поздно.

1. CSS или JavaScript, блокирующие рендеринг

У браузера уже есть контент, но он ещё не может его отрисовать.

1. Неоптимизированные hero-изображения

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

1. Web fonts задерживают отрисовку текста

Крупный заголовок может быть LCP-элементом, а загрузка шрифта может задержать или визуально изменить его.

1. Задержки client-side rendering

Если странице нужен большой JavaScript-бандл, прежде чем она сможет показать осмысленный контент, LCP страдает.

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

Начните с фактического LCP-элемента. Не оптимизируйте случайные ресурсы, пока не поймёте, что именно измеряет браузер.

Практические исправления включают:

• Отдавайте HTML быстро: используйте кэширование там, где это уместно, сокращайте работу backend, избегайте медленных редиректов.
• Оптимизируйте LCP-изображение: используйте правильные размеры, сжатие и формат.
• Не применяйте lazy-loading к hero-изображению выше первого экрана.
• Аккуратно используйте fetchpriority="high" для главного изображения, когда оно действительно является приоритетным.
• Встраивайте critical CSS только тогда, когда это заметно сокращает задержку рендеринга.
• Сокращайте JavaScript, необходимый до первой осмысленной отрисовки.
• Используйте font-display: swap или другую осознанную стратегию для шрифтов.

Изображения и шрифты часто оказываются виновниками. Для изображений компромисс — это не просто «маленький файл хорошо». Важны выбор формата, усилия на кодирование и поддержка браузерами, поэтому мы поддерживаем практическое дерево решений о том, когда AVIF лучше WebP, а когда нет. Для страниц с большим количеством текста web fonts всё ещё остаются одним из самых простых способов выиграть в производительности, потому что многие сайты отправляют больше файлов шрифтов, чем используют.

INP: реагирует ли страница на касание?

Interaction to Next Paint измеряет отзывчивость. Точнее, он смотрит на задержку между пользовательским взаимодействием и следующим визуальным обновлением после того, как браузер обработал это взаимодействие.

К взаимодействиям относятся, например:

• клик по кнопке,
• нажатие на меню,
• выбор checkbox,
• ввод текста в поле формы,
• открытие accordion.

INP заменил First Input Delay как Core Web Vital в 2024 году. Это было хорошее изменение. First Input Delay смотрел только на первое взаимодействие. INP шире: он учитывает взаимодействия на протяжении всего визита на страницу и сообщает взаимодействие с высокой задержкой как оценку отзывчивости страницы.

Простыми словами: INP выявляет страницы, которые выглядят загруженными, но ощущаются зависшими.

Вы наверняка пользовались такой страницей. Она выглядит готовой. Вы нажимаете на меню. Полсекунды ничего не происходит. Вы нажимаете снова. Затем сразу происходят две вещи. Это проблема INP.

Частые причины плохого INP

INP обычно связан с проблемами main thread. Браузер хочет ответить, но ему мешают JavaScript, работа рендеринга или расчёт layout.

Типичные причины включают:

• большие JavaScript-бандлы,
• дорогие event handlers,
• hydration в client-rendered apps,
• сторонние скрипты, конкурирующие за main thread,
• долгие задачи после загрузки страницы,
• сложные обновления DOM, вызванные небольшими взаимодействиями,
• layout thrashing, когда код многократно читает и записывает значения layout.

Маркетинговые теги, analytics, chat widgets и consent banners — всё это может вносить вклад. Это не значит «удалите всё». Это значит, что у каждого скрипта на странице есть цена, и задержка взаимодействия часто делает эту цену заметной.

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

Улучшение INP — это не столько один магический атрибут, сколько снижение конкуренции за main thread.

Полезные подходы:

• Разбивайте длинные JavaScript-задачи на меньшие части.
• Откладывайте несущественную работу до момента, когда страница уже пригодна к использованию.
• Удаляйте неиспользуемый JavaScript, а не просто минифицируйте его.
• Делайте event handlers небольшими и предсказуемыми.
• Не перерисовывайте большие части интерфейса из-за крошечных изменений состояния.
• Используйте CSS для простых визуальных состояний там, где это возможно.
• Аудируйте сторонние скрипты и загружайте их только там, где они нужны.

Также посмотрите на дизайн взаимодействий. Кнопка, которая сразу даёт визуальную обратную связь, может ощущаться более отзывчивой, даже если последующая работа занимает больше времени. Это не замена производительности, но часть хорошей инженерии интерфейсов. Наш чек-лист для доступных web buttons пересекается с этим: понятные состояния, правильная семантика и предсказуемое поведение помогают и пользователям, и браузерам.

CLS: остаётся ли страница там, где пользователь ожидает?

Cumulative Layout Shift измеряет неожиданные перемещения видимых элементов. Если пользователь начинает читать абзац, а над ним загружается реклама, изображение или баннер и сдвигает текст вниз, это вносит вклад в CLS.

CLS измеряется не в секундах. Это оценка, основанная на том, сколько контента сдвинулось и насколько далеко. Чем ниже, тем лучше.

Ключевое слово — неожиданные. Изменения layout, вызванные действием пользователя, обычно не учитываются тем же образом. Если кто-то нажимает «показать ещё» и контент раскрывается, это ожидаемо. Если через три секунды сверху появляется newsletter-баннер и сдвигает всё вниз, это нет.

Частые причины плохого CLS

Провалы CLS часто довольно обыденны:

• изображения без атрибутов width и height,
• реклама или embeds без зарезервированного места,
• cookie banners, вставленные над контентом,
• web fonts, которые подменяются шрифтами с другими метриками,
• поздно загружающиеся промо-панели,
• динамически вставляемый контент рядом с верхом страницы.

Исправление обычно состоит в том, чтобы зарезервировать место до прихода контента. Браузер должен понимать форму страницы как можно раньше.

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

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

Затем примените скучные исправления:

• Добавьте явные атрибуты width и height к изображениям.
• Используйте CSS aspect-ratio для адаптивных media containers.
• Резервируйте фиксированное или минимальное место для рекламы, embeds и iframes.
• Не вставляйте баннеры над существующим контентом после загрузки.
• Выбирайте fallback-шрифты с метриками, похожими на итоговый шрифт.
• Избегайте анимаций, которые меняют layout-свойства вроде top, left, width или height; предпочитайте transforms.

CLS — одна из немногих метрик производительности, где дисциплина побеждает изобретательность. Если на странице стабильные блоки, она обычно получает хорошую оценку.

Field data и lab data полезны, но отвечают на разные вопросы

Распространённый источник путаницы — разные инструменты показывают разные числа. Это нормально.

Field data приходят от реальных пользователей. Они отражают реальные устройства, сети, локации и условия браузера. Google Chrome User Experience Report — пример field data.

Lab data приходят из контролируемой тестовой среды. Lighthouse — знакомый пример. Они воспроизводимы и полезны для отладки, но это не то же самое, что реальный опыт ваших пользователей.

Используйте field data, чтобы понять, есть ли у пользователей реальная проблема. Используйте lab data, чтобы воспроизвести и отладить эту проблему.

Также помните, что Core Web Vitals обычно оцениваются по отдельному URL или группе URL, а не как единое абстрактное свойство вашего бренда. У главной страницы, статьи в блоге, страницы с ценами и checkout могут быть очень разные узкие места.

Разумный порядок работы

Если все три метрики плохие, возникает соблазн начать везде. Сопротивляйтесь ему.

Практичный порядок такой:

1. Сначала исправьте очевидный CLS

Отсутствующие размеры изображений и нестабильные баннеры часто дают быстрые победы.

1. Улучшите LCP для важных шаблонов

Сосредоточьтесь на страницах, которые важны: страницы товаров, landing pages, статьи, sign-up flows.

1. Исследуйте INP на реальных взаимодействиях

Нажимайте на то, на что действительно нажимают пользователи. Меню, фильтры, формы и элементы управления checkout часто показывают больше, чем начальный trace загрузки.

1. Проведите аудит сторонних скриптов

Оставьте те, которые оправдывают свою стоимость. Удалите или отложите те, которые не оправдывают.

1. Установите performance budget

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

Важный момент: не оптимизируйте ради значка. Оптимизируйте пользовательский путь. Небольшое улучшение оценки на странице с низким трафиком может быть менее важным, чем слегка несовершенное, но гораздо более быстрое взаимодействие в checkout.

<!-- tool-cta:start -->

💡 Попробуйте это: Поскольку LCP обычно связан с изображениями, уменьшите размер основного изображения с помощью Image Compressor как первый простой шаг к улучшению.

<!-- tool-cta:end -->

О чём Core Web Vitals вам не говорят

Core Web Vitals полезны, но неполны.

Они не говорят, хорош ли ваш контент. Они не говорят, понятна ли ваша навигация. Они не гарантируют доступность. Они не измеряют приватность, безопасность, доверие, читаемость или то, отвечает ли страница на вопрос пользователя.

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

Относитесь к LCP, INP и CLS как к дымовым датчикам. Когда они срабатывают, разбирайтесь. Когда они молчат, продолжайте обслуживать здание.