Что такое Core Web Vitals простыми словами?

Три метрики, которыми Google измеряет, насколько сайтом комфортно пользоваться: как быстро появляется основное содержимое (LCP), насколько быстро страница отвечает на действия (INP) и не прыгает ли вёрстка при загрузке (CLS).

Какие значения считаются нормальными?

LCP — до 2,5 секунды, INP — до 200 миллисекунд, CLS — до 0,1. Оцениваются они по реальным посетителям за 28 дней, причём по 75-му процентилю: то есть у трёх четвертей пользователей должно быть не хуже этих значений.

Сильно ли Core Web Vitals влияют на позиции?

Как фактор ранжирования они работают, но слабее релевантности содержания. Гораздо важнее прямое влияние на бизнес: медленный сайт теряет посетителей до того, как они увидят предложение, и рекламный бюджет сгорает в загрузку.

Почему в PageSpeed Insights оценка хорошая, а в Search Console метрики плохие?

Это разные данные. PageSpeed при тесте показывает лабораторное измерение на одном устройстве и канале. Search Console показывает реальных пользователей с их телефонами и интернетом. Ориентироваться при оценке сайта нужно на вторые.

Core Web Vitals простыми словами: LCP, INP и CLS

Core Web Vitals — три метрики, которыми Google формализовал понятие «сайтом удобно пользоваться». Звучит технически, но за каждой стоит бытовая ситуация, знакомая любому человеку с телефоном.

Разбираем без терминов: что измеряется, какие значения нормальны и что делать, если не проходите.

Три метрики

LCP — как быстро появилось главное

Largest Contentful Paint измеряет момент, когда на экране отрисовался самый крупный элемент первого экрана: обычно это большая картинка или заголовок.

Бытовое описание: сколько человек смотрит на пустой или полупустой экран, прежде чем поймёт, куда попал.

Норма — до 2,5 секунды. Хуже 4 секунд — плохо.

Что чаще всего портит: тяжёлые несжатые изображения на первом экране, шрифты, блокирующие отрисовку, медленный ответ сервера, отсутствие приоритета загрузки у главной картинки.

INP — как быстро сайт отвечает на действие

Interaction to Next Paint измеряет задержку между действием пользователя (нажал кнопку, открыл меню) и видимой реакцией страницы.

Бытовое описание: вы нажали на кнопку, а ничего не произошло, и вы нажимаете ещё раз.

Норма — до 200 миллисекунд. Хуже 500 — плохо.

Что портит: избыточный JavaScript, тяжёлые сторонние скрипты (чаты, виджеты, счётчики), долгие вычисления в момент клика.

CLS — не прыгает ли вёрстка

Cumulative Layout Shift измеряет, насколько элементы страницы смещаются во время загрузки.

Бытовое описание: вы уже нацелились нажать на ссылку, но тут догрузился баннер, всё уехало вниз, и вы попали не туда. Самая раздражающая из трёх проблем.

Норма — до 0,1. Хуже 0,25 — плохо.

Что портит: изображения без заданных размеров, реклама и виджеты, вставляемые в поток, шрифты, меняющие размер текста при подмене.

Как правильно смотреть значения

Здесь возникает почти всеобщая путаница.

Лабораторные данные — то, что показывает PageSpeed Insights при тесте прямо сейчас: одно устройство, один канал связи, идеальные условия. Полезны для отладки.

Полевые данные — то, что собрано с реальных посетителей за последние 28 дней. Именно они используются поиском и показываются в Search Console.

Отсюда типичная ситуация: в тесте оценка 95, а в Search Console метрики красные. Ничего противоречивого — просто ваши реальные посетители сидят на телефонах с медленным интернетом, а тест прогонялся в других условиях.

Ещё важная деталь: полевые данные считаются по 75-му процентилю. Это значит, что у 75% посетителей должно быть не хуже нормы — ориентироваться на среднее нельзя, среднее скрывает хвост.

Что важнее позиций

Core Web Vitals работают как фактор ранжирования, но заметно слабее релевантности содержания. Хороший быстрый сайт не обгонит более релевантный медленный только за счёт скорости.

Гораздо весомее прямой эффект на бизнес. Медленный сайт теряет посетителей до того, как они увидят предложение. Если вы платите за рекламу, вы платите за клики, которые не доходят до содержимого. Именно поэтому в списке того, на чём нельзя экономить, скорость стоит рядом с тестированием.

Что делать, если не проходите

По убыванию отдачи:

1. Изображения. Почти всегда главная причина плохого LCP. Современные форматы, правильные размеры под устройство, отложенная загрузка всего, что ниже первого экрана, и явный приоритет для главной картинки.

2. Сторонние скрипты. Чаты, виджеты отзывов, пиксели, счётчики. Каждый добавляет вес и портит INP. Проведите инвентаризацию: обычно половина стоит с давнего эксперимента и никому не нужна. Остальные загружайте отложенно.

3. Шрифты. Подключайте локально, ограничивайте набор начертаний, задавайте поведение подмены, чтобы текст не исчезал и не прыгал.

4. Размеры элементов. Задавайте ширину и высоту изображениям и резервируйте место под блоки, которые появляются позже. Это лечит CLS почти полностью.

5. Способ отрисовки страницы. Статическая генерация вместо сборки на каждый запрос даёт лучший старт, потому что браузер получает готовый документ.

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

Чего делать не стоит

Гнаться за сотней в PageSpeed. Оценка 100 в тесте не гарантирует зелёных полевых метрик, а последние проценты обычно даются ценой удобства.

Удалять аналитику ради скорости. Без данных вы не поймёте, окупились ли изменения. Правильный путь — отложенная загрузка, а не отказ.

Оптимизировать только главную. Метрики собираются по всем страницам. Часто худшие показатели у карточек товаров или статей, а не у главной.

Делать это разово. Метрики деградируют со временем: добавили баннер, залили тяжёлые фотографии, подключили новый виджет. Периодическая проверка — часть поддержки сайта.

Итог

Три метрики, три бытовых вопроса: быстро ли появилось содержимое, быстро ли сайт отвечает на нажатия, не прыгает ли вёрстка.

Смотрите полевые данные, а не лабораторные. Начинайте с изображений и сторонних скриптов — это две причины из трёх. И помните, что главная выгода здесь не в позициях, а в посетителях, которые дожили до вашего предложения.