Core Web Vitals: LCP, INP, CLS и как их улучшить

Что такое Core Web Vitals простыми словами

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

Разложу на бытовом языке:

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

Ключевой нюанс: Vitals считают по живым людям, которые реально заходили на сайт из Chrome, а не по одному твоему тесту с быстрого ноутбука. Google берёт 75-й перцентиль — значит, у трёх из четырёх посетителей должно быть «хорошо», чтобы метрика зачлась зелёной. Один быстрый заход ничего не доказывает.

LCP — за сколько прогружается главный экран

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

Пороги:

• ≤ 2,5 с — хорошо;
• 2,5–4 с — надо поработать;
• > 4 с — плохо.

Почему именно самый большой элемент. Google логично рассудил: пользователь считает страницу «загрузившейся», когда увидел основной контент. Мелкие иконки и футер его в этот момент не волнуют. Метрика ловит именно момент, когда экран стал осмысленным.

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

INP — насколько быстро сайт отвечает на клики

INP (Interaction to Next Paint) меряет отзывчивость: ты что-то нажал, и через сколько миллисекунд экран отреагировал видимым изменением. Метрика смотрит на все взаимодействия за визит и берёт практически худшее — ловит самый противный лаг, а не средний по больнице.

Пороги:

• ≤ 200 мс — хорошо;
• 200–500 мс — надо поработать;
• > 500 мс — плохо.

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

Главный виновник плохого INP — тяжёлый JavaScript. Браузер выполняет скрипт одним длинным куском, поток занят, и пока он считает, твой клик стоит в очереди. Отсюда ощущение «нажал — и ничего».

CLS — прыгает ли вёрстка под пальцем

CLS (Cumulative Layout Shift) — про стабильность. Метрика суммирует, насколько элементы скакали по экрану во время загрузки без твоего участия. Это безразмерное число: чем меньше, тем спокойнее страница стоит на месте.

Пороги:

• ≤ 0,1 — хорошо;
• 0,1–0,25 — надо поработать;
• > 0,25 — плохо.

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

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

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

Первое, что надо усвоить: есть два типа данных, и путать их дорого.

Полевые данные (field, CrUX) — статистика реальных пользователей Chrome за последние 28 дней. Именно её Google учитывает для ранжирования. Живая, но инерционная: правку увидишь только когда накопится новый трафик.

Лабораторные данные (lab) — один прогон в контролируемой среде с эмуляцией среднего телефона и сети. Быстро, воспроизводимо, удобно для отладки. Но это симуляция, и она может расходиться с тем, что видят твои настоящие посетители.

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

Чем мерить:

• PageSpeed Insights — показывает и полевые (если по URL хватает данных CrUX), и лабораторные. Главный рабочий инструмент: даёт оценки по трём метрикам и список конкретных рекомендаций.
• Google Search Console, отчёт Core Web Vitals — единственное место, где видно ситуацию по всему сайту сразу. Группирует страницы в «плохо / нужно улучшить / хорошо» отдельно для мобильных и десктопа. С него и начинай. Как читать GSC — в отдельном разборе.
• Наш on-page аудит — быстрый способ прогнать URL и увидеть узкие места без копания в отчётах.
• DevTools в Chrome (вкладка Performance и Lighthouse) — для глубокой отладки INP и поиска длинных задач в коде.

Начинай сверху вниз: Search Console показывает, где горит по всему сайту, PageSpeed разбирает конкретный URL, DevTools добивает точечно.

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

Цель — чтобы главный элемент экрана появился быстрее. Работаем по цепочке от сервера до картинки.

• Ускорь ответ сервера. Тормозящий бэкенд или дешёвый хостинг откладывают вообще всё. Включи кэширование, оптимизируй запросы к базе, подумай про более быстрый тариф.
• Поставь CDN. Если сервер физически далеко от пользователя, каждый байт идёт дольше. CDN раздаёт статику с ближайшей точки и заметно срезает задержку.
• Оптимизируй картинки. Чаще всего LCP-элемент — это изображение. Сжимай, отдавай в современных форматах (WebP, AVIF), задавай правильный размер под контейнер. Не грузи «фотку 4000 пикселей», если в макете она 800.
• Не ленись грузить главную картинку. Первому изображению экрана поставь приоритет загрузки и убери с него ленивую подгрузку — иначе браузер притормозит именно то, что меряет LCP.
• Разберись со шрифтами. Подключай их с font-display, чтобы текст не ждал загрузки шрифта, и предзагружай критичные файлы. Убери из шапки скрипты и стили, которые блокируют отрисовку.

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

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

• Убери лишний JavaScript. Аудит скриптов — самое доходное действие. Половина сторонних виджетов, старых счётчиков и чат-ботов висит зря и жрёт отзывчивость. Что не нужно — выкидывай.
• Разбивай длинные задачи. Одна операция, которая считается 300 мс, намертво блокирует отклик. Дели её на короткие куски и отдавай браузеру паузы, чтобы он успевал обработать клик между ними.
• Откладывай некритичное. Аналитику, баннеры, всё, что не нужно в первую секунду, грузи отложенно и после того, как страница стала интерактивной.
• Не тащи тяжёлые библиотеки ради мелочи. Огромный фреймворк ради одного слайдера — частая причина лагов на мобильных, где процессор слабее.
• Следи за сторонними тегами. Менеджеры тегов и рекламные сети умеют в одиночку убить INP. Проверяй каждого нового «жильца» через DevTools.

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

CLS чинится дисциплиной: всему, что подгружается, надо заранее зарезервировать место.

• Задавай размеры картинкам и видео. Пропиши width и height (или aspect-ratio), чтобы браузер выделил место под элемент до его загрузки и ничего не прыгало.
• Бронируй место под динамику. Реклама, эмбеды, виджеты — под них держи контейнер фиксированной высоты. Пусть лучше пустует секунду, чем толкает контент.
• Никогда не вставляй блоки над видимым контентом. Плашки «подпишись», уведомления и баннеры, которые внезапно появляются сверху, сдвигают всё вниз. Резервируй под них слот или показывай так, чтобы не двигать остальное.
• Приручи шрифты. При подмене системного шрифта на кастомный текст меняет метрики и толкает соседние элементы. Подбирай запасной шрифт близким по размеру и предзагружай основной.

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

Коротко: для Google — да, напрямую и официально. Vitals входят в набор сигналов Page Experience. Google не раз повторял: при прочих равных страница с лучшим пользовательским опытом получит преимущество. Это фактор-усилитель — он не вытащит слабый по смыслу материал в топ, но между двумя одинаково релевантными страницами быстрая победит.

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

Для Яндекса прямого фактора «Core Web Vitals» нет — это метрика Google. Но влияние идёт косвенно и вполне ощутимо. Яндекс любит быстрые сайты и учитывает скорость, а ещё сильно опирается на поведенческие сигналы. Тормозящая страница с прыгающей вёрсткой отпугивает людей: они уходят, не дочитав, растёт процент отказов, падает глубина просмотра. Ускоряя сайт под Vitals, ты одновременно улучшаешь поведенческие — и в Яндексе тоже. Как разгонять скорость — в статье про скорость загрузки сайта.

Отдельно про мобайл: он важнее десктопа. Google работает по mobile-first индексации, и для большинства тематик именно мобильная версия определяет позиции. Проверяй Vitals в первую очередь на телефонах: там слабее процессор, хуже сеть, и та же страница, что летает на десктопе, легко проваливается по INP и LCP на смартфоне. В Search Console мобильный и десктопный отчёты разделены — начинай с мобильного.

Частые вопросы

Главное