Core Web Vitals: что это и как улучшить показатели

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

Что такое Core Web Vitals и из чего они состоят

Core Web Vitals (CWV) — три ключевые метрики из более широкого набора Web Vitals. С марта 2024 года Google заменил устаревший FID (First Input Delay) на INP (Interaction to Next Paint), поэтому актуальная тройка выглядит так:

• LCP (Largest Contentful Paint) — время отрисовки самого крупного видимого элемента (обычно это hero-изображение, баннер или крупный блок текста). Отвечает на вопрос «когда пользователь увидел, что страница загрузилась».
• INP (Interaction to Next Paint) — задержка между действием пользователя (клик, тап, нажатие клавиши) и визуальным откликом интерфейса. Заменил FID и измеряет отзывчивость на протяжении всей сессии, а не только при первом взаимодействии.
• CLS (Cumulative Layout Shift) — суммарный сдвиг макета: насколько элементы «прыгают» во время загрузки. Это визуальная стабильность.

Важно различать полевые данные (field, CrUX — реальные сессии пользователей Chrome) и лабораторные (lab, Lighthouse/PageSpeed — синтетический прогон). Google ранжирует по полевым данным за последние 28 дней. Лабораторный тест полезен для отладки, но «зелёный Lighthouse» при «красном CrUX» — частая и опасная иллюзия.

Целевые пороги: нормативы

Google делит каждую метрику на три зоны. Цель должна достигаться у 75-го перцентиля — то есть для 75% сессий.

Диагностические метрики, помогающие понять причину провала: TTFB (Time to First Byte, цель < 0,8 с) и FCP (First Contentful Paint). В CWV они не входят, но напрямую влияют на LCP.

Где смотреть данные

Чтобы не работать вслепую, нужны источники field- и lab-данных:

• Google Search Console → отчёт «Основные интернет-показатели» — полевые данные CrUX, сгруппированные по URL. Главный источник для приоритизации: показывает, какие группы страниц «красные».
• PageSpeed Insights — даёт и поле (если по URL накоплен трафик), и лабораторный прогон Lighthouse с рекомендациями.
• Lighthouse в DevTools — для локальной отладки и проверки гипотез до выката.
• Яндекс.Вебмастер → «Скорость загрузки» — CWV для Яндекса как фактор не объявлены, но скорость влияет на поведенческие метрики (отказы, время на сайте), которые учитывает многорукий бандит. Для коммерческих сайтов под Яндекс это не менее важно, чем под Google.

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

LCP чаще всего проседает из-за медленного сервера и тяжёлого главного изображения.

1. Сократите TTFB. Кэширование на сервере (Redis, страничный кэш CMS), CDN для статики, HTTP/2 или HTTP/3. Медленный ответ сервера невозможно «закрасить» оптимизацией фронтенда.
2. Оптимизируйте LCP-элемент. Для hero-изображения — современные форматы (WebP, AVIF), корректный размер под вьюпорт, fetchpriority="high" и <link rel="preload">. Не применяйте к нему lazy-loading — это типичная ошибка, отодвигающая отрисовку.
3. Уберите рендер-блокирующие ресурсы. Критический CSS — инлайном, остальной — отложенно; некритичный JS — с defer/async.
4. Минимизируйте сторонние скрипты (чаты, виджеты, аналитика) — они конкурируют за главный поток.

Подробнее о фронтенд-оптимизации — в материале скорость загрузки сайта, а про работу с картинками — в оптимизации изображений для SEO.

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

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

1. Разбивайте длинные задачи. Задачи дольше 50 мс блокируют отклик. Дробите вычисления, используйте requestIdleCallback, выносите тяжёлую логику в Web Workers.
2. Сокращайте объём JS. Tree-shaking, code-splitting, удаление неиспользуемых библиотек. Чем меньше парсинга и исполнения — тем быстрее отклик.
3. Откладывайте несрочную работу. Аналитику, ремаркетинг-пиксели, инициализацию виджетов запускайте после первого взаимодействия.
4. Избегайте тяжёлых обработчиков событий на каждый скролл/ввод — используйте дебаунс и троттлинг.

Для сайтов на тяжёлых фреймворках смежная тема — JavaScript и SEO: проблемы рендеринга.

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

CLS — самая «дешёвая» в исправлении метрика: причины почти всегда механические.

1. Резервируйте место под медиа. У каждого <img> и <video> указывайте атрибуты width и height (или aspect-ratio в CSS), чтобы браузер заранее знал размер.
2. Бронируйте слоты под рекламу и встраивания. Заранее задавайте контейнерам фиксированную высоту, чтобы баннер не «раздвигал» контент при подгрузке.
3. Подключайте шрифты без скачка. font-display: optional или swap плюс <link rel="preload"> для основного шрифта — против эффекта перерисовки текста (FOIT/FOUT).
4. Не вставляйте контент над уже отрендеренным (уведомления, баннеры cookie) без зарезервированного места.

Мини-кейс: приоритизация по группам страниц

Типичный сценарий для коммерческого сайта на 1С-Битрикс. В Search Console отчёт CWV показал, что «красная» зона по LCP — только у группы карточек товара, а главная и категории в зелёной. Профилирование в Lighthouse выявило две причины: главное фото товара грузилось через lazy-loading (и потому считалось LCP-элементом с задержкой) и отдавалось в оригинальном PNG весом несколько мегабайт.

Решение свелось к трём правкам: снять lazy-loading с первого изображения карточки, добавить fetchpriority="high" и подключить отдачу в WebP с ресайзом под вьюпорт. Важен сам принцип: сначала найти проблемную группу URL по полевым данным, затем диагностировать причину в лаборатории — а не «оптимизировать всё подряд». Эффект всегда проверяется повторным замером CrUX через 28 дней.

⚠️ Риски и типичные ошибки

• Гонка за зелёным Lighthouse вместо CrUX. Лабораторный балл 100 ничего не гарантирует, если у реальных пользователей (мобильный 4G, слабые устройства) метрики в красной зоне. Ориентир — поле.
• Lazy-loading на LCP-элементе. Самая частая причина плохого LCP. Первый экран грузим жадно, ленивую загрузку — только ниже сгиба. Тонкости — в материале о lazy loading изображений.
• «Накрутка» метрик через cloaking. Отдавать роботу/тесту облегчённую версию, а пользователю — тяжёлую — ⚠️ РИСК санкций (для Google это нарушение, клоакинг). Метод чёрный, не применяем.
• Жертва контентом ради скорости. Вырезать текст, цены, отзывы и коммерческие блоки ради LCP — значит проиграть в ранжировании по другим факторам. Оптимизируем доставку, а не урезаем ценность.
• Оптимизация без замера. Любую правку проверяем повторно: CWV измеряются на реальном трафике с лагом до 28 дней.

FAQ

Влияют ли Core Web Vitals на ранжирование в Яндексе?
Напрямую как объявленный фактор — нет, Яндекс не использует метрики Google. Но скорость и стабильность влияют на поведенческие факторы (отказы, глубина, время на сайте), которые Яндекс учитывает. Поэтому работать над CWV полезно и для Яндекса, и для Google.

Чем заменили FID и почему?
С марта 2024 года FID заменён на INP. FID измерял задержку только первого взаимодействия, а INP оценивает отзывчивость на протяжении всей сессии — это более честная картина реального опыта.

Какие данные использует Google для ранжирования?
Полевые (CrUX) — реальные сессии пользователей Chrome за последние 28 дней. Lighthouse-прогон нужен для отладки, но в ранжировании участвует именно поле.

Что важнее оптимизировать в первую очередь?
Ту метрику, по которой страница в красной зоне у 75-го перцентиля в Search Console. Чаще всего это LCP (сервер и изображения) и INP (тяжёлый JS). CLS обычно правится быстрее всего.

Как быстро видно результат после правок?
Лабораторный замер меняется сразу, а полевые данные CrUX обновляются с окном до 28 дней. Поэтому реальный эффект в Search Console корректно оценивать не раньше чем через месяц после выката.

Материал подготовлен экспертами Chrome Media: технический SEO-аудит, оптимизация скорости и Core Web Vitals под Яндекс и Google.