+7-991-90-777-51
Инженерная энциклопедия Promo-Star • Автор: Алексей Смагин

Core Web Vitals (LCP, INP, CLS)

Core Web Vitals (LCP, INP, CLS) — инженерная схема и архитектура
Определение: Core Web Vitals — набор метрик Google для оценки пользовательского опыта: LCP (скорость загрузки основного контента), INP (отзывчивость на взаимодействия) и CLS (визуальная стабильность). С 2021 года входят в сигналы ранжирования, измеряются в полевых условиях через Chrome UX Report и влияют на позиции сайта в поиске.

1. Архитектура и принцип работы

Концепция представлена Google в 2020 году как эволюция Speed Update. Архитектура строится на краудсорсинге: данные собираются с реальных пользователей Chrome (анонимно, при включённой синхронизации) и агрегируются в 75-й перцентиль за 28 дней. Каждая метрика отражает отдельную грань опыта: LCP — воспринимаемую скорость, INP — интерактивность, CLS — стабильность вёрстки. Ранжирование учитывает не абсолютные значения, а прохождение порогов «good» для всех трёх метрик. С 2024 года INP заменил FID, став официальным показателем отзывчивости. Core Web Vitals интегрированы в PageSpeed Insights, Search Console и Lighthouse, а также используются в качестве сигнала в алгоритме ранжирования Google.

2. Математическая механика и триггеры ранжирования

LCP измеряет время от начала навигации до рендера самого крупного элемента в видимой области. Формула: LCP = TTFB + ресурсная задержка + время загрузки + время рендера. Порог «good» ≤ 2.5 с, «poor» > 4 с. INP фиксирует задержку всех взаимодействий (клики, тапы, нажатия клавиш) и вычисляет 98-й перцентиль; порог «good» ≤ 200 мс, «poor» > 500 мс. CLS — сумма произведений долей смещения на долю затронутой области (impact fraction × distance fraction); «good» ≤ 0.1, «poor» > 0.25. Веса метрик в ранжировании не раскрываются, но эмпирически LCP и INP влияют сильнее CLS. Триггеры пессимизации: превышение порогов «poor» хотя бы по одной метрике в 75-м перцентиле, а также отсутствие данных CrUX (сайт не ранжируется по CWV, но может терять в общем UX-сигнале). Влияние на ранжирование — умеренное: CWV работает как тай-брейкер при равной релевантности, но при систематических провалах может снижать видимость.

3. Специфика в Яндекс (YATI) vs Google

Яндекс не использует Core Web Vitals напрямую; вместо них применяет собственные метрики пользовательского опыта в YATI (Яндекс.Технологии Индексации) и ПФ (поведенческие факторы): время до первого байта, скорость отрисовки, отсутствие ошибок JS. Однако косвенно CWV коррелируют с ПФ: быстрый сайт улучшает поведенческие метрики (глубина просмотра, отказы). Google оценивает CWV через Chrome UX Report и PageSpeed Insights, а также учитывает их в Core Updates как часть общего сигнала «Page Experience». Entity Graph Google связывает сайт с сущностями и доверием, где техническое качество усиливает общий авторитет. Яндекс больше полагается на краудсорсинг Метрики и собственные замеры, тогда как Google — на данные браузера Chrome.

4. Нормативы SLA и диагностическая матрица

Параметр / МетрикаЭталон по SLAКритическая ошибка
LCP (Largest Contentful Paint)≤ 2.5 с (75-й перцентиль)> 4.0 с
INP (Interaction to Next Paint)≤ 200 мс (75-й перцентиль)> 500 мс
CLS (Cumulative Layout Shift)≤ 0.1 (75-й перцентиль)> 0.25

5. Пошаговый инженерный протокол внедрения

  • Шаг 1: Запустите аудит в PageSpeed Insights и Search Console, соберите полевые данные CrUX за 28 дней по всем трём метрикам.
  • Шаг 2: Для LCP оптимизируйте TTFB (кэширование, CDN), предзагрузите hero-изображение через preload и устраните блокирующие ресурсы.
  • Шаг 3: Для INP сократите длинные задачи (разбейте JavaScript через scheduler.yield), используйте web workers и пассивные обработчики событий.
  • Шаг 4: Для CLS задайте явные размеры изображениям и видео, зарезервируйте место под динамический контент и избегайте вставки элементов над существующими.
  • Шаг 5: Настройте RUM-мониторинг (web-vitals.js) и регрессионные тесты в CI, чтобы отслеживать метрики после каждого релиза.
// Подключение web-vitals и отправка в аналитику
import {onLCP, onINP, onCLS} from 'web-vitals';
function send(metric) {
  navigator.sendBeacon('/analytics', JSON.stringify(metric));
}
onLCP(send); onINP(send); onCLS(send);
// Формула CLS: sum(impact fraction * distance fraction)

6. Типичные ошибки при оптимизации

  • Фатальная ошибка: ориентация только на лабораторные данные Lighthouse. Избегайте: всегда сверяйтесь с полевыми данными CrUX, так как лабораторные условия не отражают реальное разнообразие устройств и сетей.
  • Фатальная ошибка: игнорирование INP после замены FID. Избегайте: тестируйте отзывчивость на мобильных устройствах с искусственным замедлением CPU и оптимизируйте длинные задачи.
  • Фатальная ошибка: борьба с CLS через фиксированные высоты без учёта адаптивности. Избегайте: используйте aspect-ratio и reserved space, а не жёсткие пиксели, чтобы избежать смещений при разных вьюпортах.
ПРОФИЛЬНАЯ УСЛУГА PROMO-STAR
Внедрим «Core Web Vitals» на вашем сайте по SLA
Услуга: Ускорение сайта и CWV →

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

Входят ли Core Web Vitals в алгоритм ранжирования Google напрямую?

Да, с 2021 года Page Experience включает CWV как сигнал. Однако вес умеренный: при равной релевантности быстрый сайт получит преимущество, но контент и ссылки остаются доминирующими факторами.

Как Яндекс учитывает Core Web Vitals?

Яндекс не использует CWV как отдельный сигнал. Вместо них применяются собственные метрики скорости и поведения в YATI и ПФ. Однако оптимизация CWV косвенно улучшает поведенческие факторы, что положительно сказывается на ранжировании в Яндексе.

Что делать, если полевые данные CrUX отсутствуют?

Для сайтов с малой аудиторией CrUX может не иметь данных. В этом случае ориентируйтесь на лабораторные замеры Lighthouse и RUM-собственные сборы. Google не пессимизирует за отсутствие данных, но рекомендует стремиться к порогам «good».