Core Web Vitals

Откуда взялись Core Web Vitals и почему это важно

Google давно стремится ранжировать сайты не только по содержанию, но и по удобству их использования. До 2020 года существовало множество разрозненных сигналов — от скорости ответа сервера до отсутствия переполнения текста. Это было неудобно и для разработчиков, и для поисковых ботов. Поэтому компания объединила ключевые пользовательские метрики в единый набор — Core Web Vitals. С июня 2021 года они стали обязательной частью обновления Page Experience, которое влияет на ранжирование. Это не просто “скорость сайта”, а именно восприятие загрузки реальным человеком. Например, если сервер отвечает за 0.1 секунды, но тяжёлый JavaScript блокирует отрисовку текста на 4 секунды — пользователь уйдёт, и метрика LCP это покажет.

Как устроены Core Web Vitals и что они измеряют

Каждая метрика отвечает за конкретный аспект взаимодействия. LCP (Largest Contentful Paint) показывает, когда загружается самый крупный видимый элемент — обычно это заголовок, картинка или видео. Хороший LCP должен быть до 2.5 секунд. INP (Interaction to Next Paint) — это отзывчивость: насколько быстро страница отвечает на клик или тап. Норма — до 200 миллисекунд. CLS (Cumulative Layout Shift) измеряет визуальную стабильность: если элементы прыгают, когда пользователь читает, это плохо. Допустимый порог — менее 0.1. Данные для этих метрик собираются Google через реальный Chrome Browser (так называемые полевые данные), а также через лабораторные тесты в Lighthouse. Для разработчика важно понимать: метрики не статичны. Одна и та же страница может иметь хороший LCP на быстром телефоне и ужасный на старом Android. Поэтому Google использует 75-й перцентиль всех сессий пользователя — так отсекаются случайные выбросы.

Практический пример: как одна картинка портит LCP

Представьте сайт интернет-магазина. Главный баннер — это большое изображение, которое загружается через тяжёлый CSS-спрайт. Разработчик проверил скорость в PageSpeed Insights и получил LCP 3.8 секунды — это красная зона. Причина: изображение не имеет атрибута fetchpriority="high", браузер загружает его после JavaScript и шрифтов. Решение занимает 15 минут: добавить приоритетную загрузку, сжать картинку до WebP и сделать её размеры явными. После этих правок LCP падает до 1.9 секунды. Аналогично с CLS: если для слайдера не задана фиксированная высота, при подгрузке следующего слайда контент прыгает на 0.2 — это уже плохо. Достаточно обернуть слайдер в контейнер с высотой, чтобы метрика вошла в норму. Такие точечные исправления не требуют переделки сайта, но дают ощутимый рост позиций.

Типичная ошибка: погоня за идеальным счётом в Lighthouse

Многие команды ошибочно считают, что Core Web Vitals — это то же самое, что зелёная оценка в Lighthouse. Но Lighthouse показывает лабораторные данные с одного устройства и с синтетическими условиями сети. Реальные полевые данные зависят от устройств пользователей, их местоположения и типа соединения. Бывает, что сайт получает 95 баллов в Lighthouse, но в Search Console видно, что LCP у 70% пользователей больше 4 секунд. Причина — тяжёлый сторонний скрипт, например чат-виджет или пиксель ретаргетинга, который грузится на реальных устройствах медленнее, чем в тестовой среде. Другая распространённая ошибка — оптимизировать только главную страницу, игнорируя внутренние. Google учитывает Core Web Vitals для каждой страницы, но особенно чувствителен к разделам с большим количеством медиа — каталогам, статьям, блогам. Правильный подход — мониторить метрики через отчёт “Основные веб-показатели” в Search Console, группировать проблемные URL и исправлять их по приоритету. И не забывайте: Core Web Vitals — это не чек-лист, а ориентир на качество пользовательского опыта. Если сайт быстрый и стабильный для реальных посетителей, метрики будут хорошими автоматически.