LCP, INP, CLS — нормы 2026 и как мерить

Что такое Core Web Vitals

Core Web Vitals (CWV) — три метрики качества пользовательского опыта от Google. Официальный ранжирующий фактор с июня 2021.

В 2024 Google заменил FID (First Input Delay) на INP (Interaction to Next Paint). Теперь три метрики:

• LCP — скорость загрузки
• INP — скорость реакции
• CLS — стабильность вёрстки

Нормы Google 2026

Цель: все три в зелёной зоне на 75% сессий.

LCP — Largest Contentful Paint

Что измеряет

Время загрузки самого большого элемента видимой области:

• Картинка hero
• Большой заголовок
• Видео-постер

Почему важно

Пользователь считает страницу «загруженной», когда видит основной контент.

Норма

• < 2.5s — хорошо
• 2.5-4.0s — нужно улучшить
• > 4.0s — плохо

Что влияет

• Скорость сервера (TTFB)
• Размер ресурсов
• Render-blocking JS/CSS
• Очередь загрузки

Как улучшить

1. CDN для статики
2. WebP/AVIF картинки
3. Preload LCP-элемента
4. Critical CSS inline
5. SSR/SSG вместо CSR

Как ускорить →.

INP — Interaction to Next Paint

Что измеряет

Время от взаимодействия пользователя (клик, тап, нажатие клавиши) до визуального ответа браузера.

Почему важно

Если кнопка не реагирует 500ms — пользователь думает, что «сайт сломался».

Норма

• < 200ms — хорошо
• 200-500ms — нужно улучшить
• > 500ms — плохо

Что влияет

• Long tasks на main thread (> 50ms)
• Тяжёлый JavaScript
• Third-party скрипты
• Неоптимизированные event handlers

Как улучшить

1. Разбить long tasks (setTimeout, scheduler.yield)
2. Уменьшить JS bundle (code splitting)
3. Web Workers для тяжёлых вычислений
4. Debounce input handlers
5. Virtualization длинных списков

Что заменил INP

INP заменил FID (First Input Delay) в марте 2024.

FID измерял только первое взаимодействие. INP — все взаимодействия за сессию (худший 98-й перцентиль).

CLS — Cumulative Layout Shift

Что измеряет

Накопленный сдвиг элементов на странице — насколько контент «прыгает» во время загрузки.

Почему важно

Пользователь нажимает на кнопку → она «прыгнула» → клик на другой элемент → раздражение.

Норма

• < 0.1 — хорошо
• 0.1-0.25 — нужно улучшить
• > 0.25 — плохо

Что влияет

• Картинки без width/height
• Шрифты без font-display
• Поздно подгружающаяся реклама
• Embed'ы (YouTube, Twitter) без размеров
• Dynamic content сверху

Как улучшить

1. width/height на картинках:

``html <img src="..." width="800" height="600" alt="..."> ``

1. font-display: swap:

``css @font-face { font-display: swap; } ``

1. aspect-ratio для embeds:

``css .embed { aspect-ratio: 16 / 9; } ``

1. Резервируем место для рекламы и динамики

1. Skeleton screens вместо «прыгающего» контента

Как мерить Core Web Vitals

1. PageSpeed Insights (Lab + Field)

pagespeed.web.dev

• Lab data: Lighthouse, синтетический тест
• Field data: реальные пользователи (CrUX)

2. Google Search Console

GSC → Experience → Core Web Vitals — реальные данные ваших пользователей.

Отчёт по группам страниц:

• Mobile / Desktop
• Good / Needs Improvement / Poor

3. Chrome DevTools

F12 → Performance → Record → анализ.

4. Web Vitals extension

Расширение Chrome — real-time метрики на любой странице.

5. Lighthouse

В Chrome DevTools → Lighthouse → Mobile/Desktop.

6. RUM (Real User Monitoring)

Сервисы для production:

• web-vitals библиотека от Google (бесплатно)
• SpeedCurve, Calibre (платные)
• Cloudflare Analytics (часть RUM)

<script>
  import {onLCP, onINP, onCLS} from 'web-vitals';
  onLCP(console.log);
  onINP(console.log);
  onCLS(console.log);
</script>

7. Я.Метрика

Раздел «Скорость» → метрики LCP, INP, CLS на ваших пользователях.

8. CrUX (Chrome User Experience Report)

Открытые данные из реальных Chrome-пользователей: developer.chrome.com/docs/crux.

Lab vs Field

Lab data

Синтетические тесты в идеальных условиях.

Плюсы: воспроизводимость, контроль. Минусы: не отражает реальность.

Field data

Реальные пользователи с реальной сетью и устройствами.

Плюсы: реальная картина. Минусы: нужно время для накопления, нужен трафик 1000+ в день.

Что использовать

Field — основа для оценки. Lab — для отладки и быстрых проверок.

Google ранжирует на основе Field данных (CrUX).

Реальные числа в нишах 2026

Желаемые для топ-10

E-commerce:

• LCP: 1.5-2.0s
• INP: 100-150ms
• CLS: 0.02-0.05

Контентные сайты:

• LCP: 1.0-1.5s
• INP: 80-120ms
• CLS: 0.01-0.03

SaaS лендинги:

• LCP: 1.0-1.8s
• INP: 100-180ms
• CLS: 0.02-0.05

Медиа / новости:

• LCP: 1.5-2.5s (реклама часто мешает)
• INP: 150-250ms
• CLS: 0.05-0.10

Чек-лист CWV-оптимизации

LCP

• [ ] LCP-элемент идентифицирован
• [ ] Preload поставлен
• [ ] CDN для статики
• [ ] WebP/AVIF
• [ ] Critical CSS inline
• [ ] TTFB < 600ms

INP

• [ ] Long tasks разбиты
• [ ] JS bundle минимизирован
• [ ] Third-party скрипты под контролем
• [ ] Web Workers для тяжёлой работы
• [ ] Debounce на input

CLS

• [ ] width/height на картинках
• [ ] font-display: swap
• [ ] aspect-ratio для embeds
• [ ] Реклама в зарезервированных контейнерах
• [ ] Никакого dynamic injection сверху

Общее

• [ ] PageSpeed Mobile > 80
• [ ] GSC Core Web Vitals «хорошо» на 75%+ URL
• [ ] RUM настроен
• [ ] Регулярный мониторинг

Анти-паттерны

❌ Только Lighthouse

Field data важнее.

❌ Игнор GSC

GSC показывает реальные проблемы.

❌ «Оптимизация под балл», не пользователя

Балл 100, но реальные пользователи страдают → бессмысленно.

❌ Игнор INP

Старая привычка с FID. INP жёстче, требует серьёзной оптимизации.

❌ Без мониторинга после деплоя

После каждого изменения нужно проверять, не упали ли метрики.

Связь с SEO

Прямое влияние

CWV — официальный фактор ранжирования. В равных условиях:

• Зелёный CWV > жёлтого > красного

Косвенное влияние

• Bounce rate ниже у быстрых сайтов
• Время на сайте выше
• Конверсия выше → больше денег
• AI Overview цитирует быстрые источники

Итог

Core Web Vitals в 2026 — не опция, а обязательное условие. Зелёная зона по всем трём = базовый минимум для топ-10.

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

Прогнать бесплатный SEO-аудит →