Core Web Vitals: что означают LCP, CLS и INP и как проверить сайт

Часть 3 из 6 · Серия «Скорость сайта без магии»

Во второй части мы искали причину медленной загрузки по симптому: долгий белый экран, поздняя картинка, нерабочие кнопки. Это язык владельца сайта, и он честный.

Но разработчик, отчёт и Google говорят на другом языке — на языке метрик. Чтобы эти два разговора не расходились, нужен словарь.

Хорошая новость: словарь короткий. В Core Web Vitals всего три метрики, и каждая описывает ровно то ощущение, которое вы и так замечали.

Три метрики — три ощущения

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

Дальше разберём каждую: что именно измеряется, какой порог считается хорошим, почему метрика портится и что с этим делать.

Пороги: какие значения считаются хорошими

Google публикует границы для всех трёх метрик. Значения ниже взяты из документации web.dev на дату подготовки статьи.

Важная деталь, которую почти всегда пропускают: оценка берётся не по среднему посетителю, а по 75-му процентилю загрузок, отдельно для мобильных и десктопных устройств.

Это значит:

LCP «хорошо» = у 75 из 100 загрузок
               главный элемент появился быстрее 2,5 секунды

Средний результат может выглядеть прилично, пока четверть посетителей ждёт вдвое дольше. Именно поэтому владельцу сайта, у которого «всё быстро открывается», отчёт показывает красную зону: у него самого загрузка попадает в удачные 25%.

LCP: когда появляется главный элемент

Largest Contentful Paint отмечает момент, когда в видимой области отрисовался самый крупный элемент содержимого. Обычно это главная фотография, баннер или крупный заголовок.

Кандидатами считаются изображения, кадры видео, элементы с фоновой картинкой из CSS и блоки с текстом. То есть LCP почти всегда указывает на конкретный объект, который можно открыть и посмотреть.

Почему LCP сайта бывает большим

Причины выстраиваются в ту же цепочку, что и во второй части:

• сервер долго отдаёт HTML — отсчёт начался, а браузеру ещё нечего рисовать;
• главное изображение весит слишком много или приходит в неудачном формате;
• картинка обнаруживается поздно, потому что подставляется скриптом или стилем;
• отрисовку задерживают стили и шрифты;
• к главному изображению применили отложенную загрузку.

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

«Слишком большой LCP на сайте на телефоне»

Отдельный частый случай: на компьютере метрика в зелёной зоне, на телефоне — в красной. Это не сбой проверки.

У телефона медленнее соединение и слабее процессор, а мобильная вёрстка нередко загружает то же полноразмерное изображение, что и десктопная, добавляя сверху собственное меню и виджеты. Разрыв между устройствами — нормальное явление, и именно мобильный результат обычно важнее: у большинства публичных сайтов основной трафик приходит с телефонов.

Что проверить в первую очередь:

1. какой именно элемент отчёт называет LCP-элементом;
2. сколько весит этот файл и в каких размерах он показывается;
3. не стоит ли на нём отложенная загрузка;
4. сколько времени ушло на ответ сервера до начала отрисовки.

Работа с изображениями — тема четвёртой части, стили и шрифты — пятой, ответ сервера — шестой.

CLS: насколько сильно прыгает страница

Cumulative Layout Shift измеряет неожиданные сдвиги содержимого во время загрузки. Это единственная метрика без секунд: результат — безразмерное число.

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

Важное уточнение, которое снимает половину вопросов: сдвиги, вызванные действием пользователя, не учитываются. Если содержимое сдвинулось в течение 500 миллисекунд после нажатия или клика — например, вы сами раскрыли пункт меню или аккордеон, — это ожидаемое поведение, и в метрику оно не попадает. Наказывают только за прыжки, которых человек не просил.

Отчего страница прыгает

• у изображения или видео не заданы размеры, и место под них не зарезервировано;
• баннер, уведомление о cookie или рекламный блок вставляется сверху уже после отрисовки;
• поздно загрузившийся шрифт меняет метрики текста, и абзацы переезжают;
• содержимое подгружается скриптом и вклинивается между готовыми блоками.

Хорошая новость: CLS сайта чаще других метрик чинится дёшево. Достаточно задать размеры медиа и заранее зарезервировать место под блоки, которые появляются позже. Плавные анимации через CSS-трансформации сдвигами не считаются, поэтому движение интерфейса само по себе метрику не портит.

INP: как быстро страница отвечает на действие

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

В отличие от прежней метрики отклика, INP смотрит не на первое взаимодействие, а на все: клики, касания и нажатия клавиш за всё время жизни страницы. С 12 марта 2024 года INP официально входит в Core Web Vitals вместо First Input Delay.

Внутри метрики три части: задержка перед началом обработки события, работа обработчика и время до появления кадра на экране. Практический вывод простой: INP сайта портится тогда, когда браузер занят выполнением JavaScript.

Что проверить:

• сколько сторонних скриптов работает на странице;
• когда запускаются чат, аналитика и рекламный код;
• не выполняется ли тяжёлая обработка прямо в момент нажатия;
• отличается ли поведение на телефоне от поведения на компьютере.

Здесь особенно заметен разрыв между устройствами: то, что мощный процессор проглатывает незаметно, на недорогом телефоне превращается в паузу после нажатия. Подробно скрипты разбираются в пятой части.

Как проверить сайт по Core Web Vitals

У метрик два источника данных, и они отвечают на разные вопросы — мы говорили об этом в первой части.

Лабораторный запуск. Страница открывается в контролируемых условиях здесь и сейчас. Так удобно искать причину и проверять исправление: результат меняется сразу. Но лаборатория показывает один смоделированный запуск, а не опыт ваших посетителей. INP в лабораторных условиях полноценно не измеряется — метрике нужны реальные действия человека.

Полевые данные. Агрегированный опыт настоящих посетителей Chrome. Именно они оцениваются по 75-му процентилю и именно они отвечают на вопрос «а как на самом деле у людей». Взамен они инертны: после исправления поле сдвигается постепенно, и у страницы с небольшим трафиком полевых данных может не быть вовсе.

Отсюда рабочий порядок:

поле      → есть ли проблема у реальных посетителей
лаборатория → в чём причина и помогло ли исправление
поле      → подтверждение через несколько недель

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

Проверка в Turbo

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

Для разбора метрик это удобно тем, что не нужно самому связывать «LCP 4,8 с» с конкретным файлом: отчёт показывает, какие ресурсы за этим стоят. Ссылку на отчёт можно сохранить и отправить разработчику.

Чего не стоит ждать от зелёных метрик

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

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

• зелёная зона не отменяет слабого текста и отсутствия нужного товара;
• красная зона у страницы с уникальным предложением не выкидывает её из поиска;
• три метрики не описывают всё — они описывают три конкретных ощущения.

И ещё одно: метрики не заменяют проверку ключевого действия. Если LCP улучшился, а кнопка покупки по-прежнему появляется последней, работа сделана не там.

Чек-лист по метрикам

[ ] известен LCP-элемент страницы (какой именно объект)
[ ] проверено, не стоит ли на нём отложенная загрузка
[ ] у изображений и видео заданы размеры
[ ] место под баннеры и уведомления зарезервировано
[ ] известно, какие сторонние скрипты работают на странице
[ ] мобильный и десктопный результаты сравнивались отдельно
[ ] полевые данные проверены, если они есть

Короткие ответы на частые вопросы

Что такое Core Web Vitals?

Это три метрики Google, описывающие опыт посетителя на странице: LCP — как быстро появляется главный элемент, INP — как быстро страница отвечает на действие, CLS — насколько сильно содержимое прыгает во время загрузки. Они оценивают удобство загрузки, а не качество текста или дизайна.

Какие метрики входят в Core Web Vitals и какие пороги считаются хорошими?

LCP, INP и CLS. Хорошими считаются LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1. Оценка берётся по 75-му процентилю загрузок отдельно для мобильных и десктопных устройств, то есть по опыту большинства посетителей, а не по среднему.

Как проверить сайт по Core Web Vitals?

Запустите проверку страницы в PageSpeed Insights или Turbo: лабораторный замер покажет причину и реакцию на исправление, а блок полевых данных — как страница работает у реальных посетителей Chrome. Полевых данных может не быть у страниц с небольшим трафиком: это не ошибка, просто статистики не хватило.

Слишком большой LCP на сайте на телефоне — что делать?

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

Что такое CLS сайта и что показывает INP сайта?

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

Что дальше

Теперь у симптомов есть имена, а у имён — пороги. Дальше серия переходит от измерений к исправлениям.

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

Посмотреть значения Core Web Vitals своей страницы и причины, которые за ними стоят, можно бесплатно на turbo.siteko.net.