Core Web Vitals: это три показателя Google, которые описывают опыт пользователя на странице: как быстро появляется основной контент (LCP), как быстро сайт реагирует на клик или тап (INP) и насколько макет «прыгает» во время загрузки (CLS). Пороги «хорошо» на момент публикации: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1, и считают их по данным реальных посетителей, а не по одному тесту на компьютере разработчика. Ниже разбираем, что именно измеряет каждая метрика, где посмотреть свои цифры, почему они часто плохие и что с этим делать.
Google ввёл набор Web Vitals в 2020 году, чтобы свести разговор о скорости загрузки сайта к нескольким понятным числам. «Core», то есть основные, это те три, которые попадают в ранжирование и в отчёты Search Console.
Largest Contentful Paint измеряет время от начала перехода до момента, когда в видимой части экрана отрисовался самый крупный элемент: баннер, заголовок, фото товара. Это не «полная загрузка», а именно момент, когда человек видит, что страница уже «есть». Если LCP равен 5 секундам, посетитель эти пять секунд смотрит на пустой экран.
Interaction to Next Paint смотрит на все клики, тапы и нажатия клавиш за визит и берёт фактически худший из них (с небольшой поправкой на очень длинные сессии). Измеряет задержку от действия до следующего обновления экрана. INP официально заменил First Input Delay 12 марта 2024 года, так что если в старых чек-листах ещё фигурирует FID, их пора обновить. Разница принципиальная: FID считал только первое взаимодействие, INP смотрит на весь визит, поэтому «подвисание» фильтра в каталоге или корзины теперь тоже идёт в зачёт.
Cumulative Layout Shift, это не время, а безразмерный показатель: сумма неожиданных сдвигов элементов. Классика жанра: человек целится в кнопку, сверху догружается баннер, кнопка уезжает, клик попадает в рекламу. Каждый такой сдвиг добавляет баллов к CLS.
Google делит каждую метрику на три зоны. Чтобы страница «прошла» проверку, все три показателя должны быть в зелёной зоне на 75-м перцентиле: то есть как минимум три четверти реальных загрузок должны укладываться в порог.
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | от 2,5 до 4 с | больше 4 с |
| INP | до 200 мс | от 200 до 500 мс | больше 500 мс |
| CLS | до 0,1 | от 0,1 до 0,25 | больше 0,25 |
Обратите внимание на 75-й перцентиль. Сайт может открываться за секунду из офиса по оптоволокну и при этом не проходить CWV, потому что четверть посетителей заходит со старых Android-телефонов через мобильный интернет. Именно поэтому мобильная версия почти всегда хуже десктопной, и именно её Google смотрит в первую очередь.
Это самая частая путаница, с которой мы в Query сталкиваемся на консультациях. Есть два источника данных, и показывают они разное.
Практический вывод: оценивайте себя по полевым данным, а лабораторный отчёт используйте как список подсказок. И не удивляйтесь, когда после исправлений полевые цифры меняются не сразу: окно 28 дней, изменения «доезжают» постепенно.
PageSpeed Insights (PSI): бесплатный инструмент Google, вводите URL и получаете два блока: оценку Core Web Vitals по полевым данным (мобильные и десктоп отдельно) и лабораторный аудит с рекомендациями. Это первое, что стоит открыть. Оценка производительности от 0 до 100, которую все любят скриншотить, относится только к лабораторной части и в ранжировании не участвует. Гнаться за 100 баллами не нужно; нужно, чтобы полевые метрики были зелёными.
Отчёт Core Web Vitals в Google Search Console показывает картину по всему сайту: сколько URL «хороших», сколько «требуют улучшения», сколько «плохих», отдельно для мобильных и десктопа. Страницы там сгруппированы по шаблону: если плохо в одной карточке товара, плохо и в остальных, так что исправление шаблона закрывает сотни URL сразу. Это самый удобный способ расставить приоритеты: смотрите, какая группа самая большая и какая метрика в ней провалена.
Для регулярного контроля есть ещё CrUX Dashboard в Looker Studio и расширение Web Vitals для Chrome, которое показывает метрики прямо во время просмотра страницы. Разработчикам удобнее Lighthouse в DevTools, там же вкладка Performance для поиска конкретного тяжёлого скрипта.
Причины повторяются от сайта к сайту. По нашим наблюдениям, в большинстве случаев проблема не одна большая, а пять-шесть средних, которые вместе и дают красную зону.
| Метрика | Порог «хорошо» | Типичная причина | Что сделать |
|---|---|---|---|
| LCP | до 2,5 с | Тяжёлое фото на первом экране, медленный сервер (TTFB больше 800 мс), рендер-блокирующие CSS и JS | Сжать изображения и перевести в WebP/AVIF, главному фото задать fetchpriority="high", включить кеш и CDN, вынести некритичные CSS/JS из <head> |
| INP | до 200 мс | Сторонние скрипты (чаты, пиксели, виджеты), тяжёлый фреймворковый JS, длинные обработчики кликов | Убрать лишние скрипты, остальные грузить отложенно (defer, async), разбивать длинные задачи на части, проверить время ответа сервера на AJAX-запросы |
| CLS | до 0,1 | Изображения и видео без размеров, баннеры и реклама, вставляемые сверху, подгрузка веб-шрифтов со «скачком» текста | Прописать width/height всем медиа, резервировать место под баннеры, шрифты отдавать с font-display: swap и preload |
Несколько уточнений по пунктам, которые чаще всего оказываются «той самой» причиной.
Изображения. Слайдер на главной с пятью фото по 2 МБ каждое, это стандартная история на сайтах, сделанных несколько лет назад. Первое фото и есть LCP-элемент, и весить оно должно не больше 150-200 КБ. Остальные слайды можно догружать позже.
Шрифты. Три семейства по четыре начертания, подключённые с Google Fonts, дают и задержку LCP, и скачок CLS, когда системный шрифт подменяется на кастомный. Оставьте два начертания, отдавайте их со своего сервера в формате WOFF2.
Сторонние скрипты. Онлайн-чат, несколько рекламных пикселей, карта, виджет отзывов: каждый тянет свой JS, и именно они чаще всего портят INP. Посчитайте, какие реально используются. Ненужный отключайте; нужный грузите после первого взаимодействия или через Tag Manager с задержкой.
Хостинг и TTFB. Time to First Byte, время до первого байта ответа сервера, это нижняя граница для LCP: если сервер думает 1,5 секунды, LCP меньше 2,5 физически не получится. Дешёвый shared-хостинг, отсутствие кеша страниц, тяжёлые запросы к базе, всё это видно в PSI как «Сократите время ответа сервера». Иногда самое дешёвое решение, это просто включить серверный кеш и переехать на нормальный тариф.
Часть этого закрывает стандартная техническая SEO-оптимизация, а более глубокие вещи вроде переписывания шаблонов или замены слайдера уже относятся к доработке сайта руками разработчика. В Query мы обычно делаем это в одной связке: аудит показывает, что именно тормозит, разработчик исправляет, а полевые данные подтверждают результат.
Честный ответ: влияют, но не так, как иногда пугают. Google подтверждает, что Core Web Vitals входят в сигналы «опыта страницы», однако это один из многих факторов, и релевантность контента весит заметно больше. Сайт с плохими метриками, но лучшим ответом на запрос, как правило, обойдёт быстрый сайт с пустой страницей. Работает это скорее как фильтр среди равных: когда конкуренты близки по содержанию, зелёная зона даёт преимущество.
А вот влияние на конверсию прямое и заметное без всякого Google. Медленная страница теряет часть посетителей ещё до первого экрана, скачки макета приводят к ошибочным кликам, а «подвисание» кнопки «Купить» на полсекунды ощущается как сломанный сайт. Поэтому мы советуем смотреть на CWV не как на SEO-галочку, а как на показатель того, сколько денег утекает через скорость загрузки сайта. Подробное описание метрик и методики измерения есть в официальной документации Google на web.dev/vitals.
.jpg "Индексация сайта простыми словами: как работает и как проверить")
.jpg "Идеи для интернет-магазина: перспективные ниши и как выбрать свою")
.jpg "Электронная коммерция: что такое eCommerce и как он работает")
.jpg "Продвижение сайта вечными ссылками и поведенческими факторами: как совместить")
