Core Web Vitals 2026: LCP, CLS, INP — что это и как улучшить — Блог SEOAdmin

Что такое Core Web Vitals и зачем они

Core Web Vitals (CWV) — три ключевых показателя пользовательского опыта от Google. Влияют на ранжирование в мобильной и десктопной выдаче с 2021 года.

В 2024 году Google заменил FID (First Input Delay) на INP (Interaction to Next Paint). Сейчас актуальная тройка:

Метрика	Что измеряет	Норма
LCP (Largest Contentful Paint)	Время до отрисовки самого крупного элемента (обычно главного баннера или заголовка)	< 2.5 сек
CLS (Cumulative Layout Shift)	Накопленный сдвиг layout-а — насколько «прыгает» страница при загрузке	< 0.1
INP (Interaction to Next Paint)	Задержка между действием пользователя (клик, тап) и визуальным ответом	< 200 мс

Все три должны быть «хорошими» (зелёными) на 75-м перцентиле реальных пользователей. То есть 3 из 4 пользователей должны видеть метрики ниже порога.

Откуда Google берёт данные

Из CrUX (Chrome User Experience Report) — анонимной телеметрии Chrome. Если у сайта < 200 уникальных пользователей в месяц, данных в CrUX нет, и Core Web Vitals тогда не учитываются в ранжировании. Это «лазейка» для новых сайтов: сначала наберите трафик, потом оптимизируйте.

Проверить свои CWV можно тремя способами:

PageSpeed Insights (pagespeed.web.dev) — основной инструмент Google. Показывает и Field Data (реальные пользователи), и Lab Data (синтетический тест).
Search Console → «Основные интернет-показатели» — список URL с проблемами.
Онлайн-проверка скорости на нашем сайте — Lab Data + рекомендации в один клик.

LCP — главное узкое место

LCP — это самый частый «красный» показатель. Обычно проблемы из-за:

Тяжёлой картинки в hero-блоке. Главный баннер размером 5 МБ без WebP — гарантированный LCP > 4 сек.
Шрифтов, блокирующих рендеринг.
Tag manager / аналитики в <head> синхронно.
Server response time > 1 сек (тяжёлый бэкенд, отсутствие кеша).
JS-фреймворков без SSR — пустой <div id="root"> пока React/Vue не загрузятся.

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

Сожмите главную картинку. Используйте WebP или AVIF. Размер — точно по width в CSS, без двукратного запаса. Включите loading="eager" именно для hero-картинки (не lazy, иначе будет ждать).

<link rel="preload"> для главной картинки и шрифта:

<link rel="preload" href="/hero.webp" as="image">
<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>

Уберите блокирующий рендер JS. Все <script> в <head> — с defer или в конец <body>.
font-display: swap в @font-face — текст не будет «невидимым» во время загрузки шрифта.
Включите HTTP/2 или HTTP/3 на сервере. Параллельная загрузка ресурсов.
CDN для статики (Cloudflare, Selectel, BunnyCDN). Сокращает задержку на 100-300 мс.
Кеш на сервере. Готовый HTML страницы должен отдаваться за < 200 мс. Если бекенд тяжёлый — кешируйте на nginx/varnish.

CLS — самая раздражающая метрика для пользователя

CLS = сумма «прыжков» layout-а во время загрузки. Когда вы пытаетесь кликнуть кнопку, а баннер сверху подгружается и сдвигает её вниз — это CLS.

Норма: < 0.1. Плохо: > 0.25.

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

Зафиксируйте размеры картинок. Атрибуты width и height обязательно. Браузер заранее зарезервирует место:
```
<img src="/photo.jpg" width="800" height="600" alt="...">
```
Размеры рекламных блоков заранее в CSS:
```
.ad-slot { min-height: 250px; }
```
Шрифты с font-display: optional или используйте font-matching (резервный шрифт похожих размеров).
Анимации только через transform и opacity, не через top/left/width/height.
Не вставляйте контент над существующим. Если нужен баннер — пусть он появляется в зарезервированном слоте, а не «врывается».
Cookie-баннер — лучше в overlay (поверх), а не в push-слое сдвигающем контент.

INP — новая метрика 2024 года

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

Норма: < 200 мс. Плохо: > 500 мс.

Что мерится: клик, тап, нажатие клавиши. Не считаются: скролл, наведение.

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

Тяжёлые JS-операции в requestIdleCallback или Web Worker. Главный поток должен быть свободен для UI.
Дебаунс / тротлинг на input-ах поиска, фильтрах. Не дёргайте API на каждое нажатие клавиши.
Уменьшите Long Tasks (> 50 мс) — разбейте на меньшие. В DevTools → Performance видно красные «long tasks».
Тяжёлая аналитика → defer. Yandex Metrika, Google Analytics, Tag Manager — после load.
React: используйте useTransition / useDeferredValue для рендеров «не блокирующих UI».
Lazy-load всё некритичное — комментарии, виджеты соцсетей, чат-боты.
Удалите неиспользуемые JS-библиотеки. Часто на сайте 80% lodash, но используются только 3 функции. Tree-shaking + бандл-анализ.

Дополнительные метрики

Помимо CWV, в PageSpeed Insights вы увидите:

FCP (First Contentful Paint) — первый видимый контент. Норма < 1.8 сек.
TTFB (Time to First Byte) — отклик сервера. Норма < 600 мс.
TBT (Total Blocking Time) — суммарное время блокировки main thread. Связан с INP.
Speed Index — общая скорость наполнения экрана.

Они полезные диагностики, но в ранжирование не входят прямо.

Инструменты замера

Инструмент	Тип данных	Когда использовать
PageSpeed Insights	Field + Lab	Базовая диагностика, основной источник
Lighthouse в DevTools	Lab	Дебаг конкретной страницы
WebPageTest	Lab	Подробные waterfall, эмуляция 3G
CrUX Dashboard	Field	История CWV за месяцы
Search Console	Field	Список URL с проблемами
SEOadmin Speed	Lab	Быстрая проверка с рекомендациями

Что делать дальше

Проверьте текущие CWV сайта: онлайн-замер скорости — получите LCP, CLS, INP за минуту.
Откройте Search Console → «Основные интернет-показатели» — увидите конкретные URL с проблемами.
Найдите 3-5 главных проблемных страниц — обычно главная + категория + 2-3 типа карточек товара.
Закройте «низковисящие фрукты»: сжатие картинок, defer для JS, width/height на <img>, font-display: swap.
Через 28 дней перепроверьте — CrUX обновляется каждые 28 дней, реальные пользователи дают новые данные.

CWV — это не «оптимизация ради Google». Это реальный пользовательский опыт. Сайт, который грузится за секунду без прыжков и тормозов, конвертит в 2-3 раза лучше — независимо от поисковиков.

🚀