Core Web Vitals: как ускорить сайт и что влияет на оценку

Core Web Vitals — это три метрики Google, которые измеряют, как быстро пользователь видит главное содержимое страницы (LCP), как быстро она реагирует на действия (INP) и не прыгает ли вёрстка при загрузке (CLS). Хорошими считаются LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 у 75% посещений. Улучшают их прежде всего картинки, шрифты, объём JavaScript и скорость сервера.

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

Что такое Core Web Vitals и почему они важны?

Core Web Vitals — набор метрик пользовательского опыта, которые Google использует как один из сигналов ранжирования и публикует по реальным посещениям в Chrome. Важнее позиций в поиске то, что медленная и нестабильная страница теряет посетителей и конверсии: люди уходят, не дождавшись загрузки, и промахиваются по кнопкам, которые сдвинулись.

Метрика	Что измеряет	Хорошо	Требует улучшения	Плохо
LCP (Largest Contentful Paint)	Время отрисовки самого крупного элемента на первом экране	до 2,5 с	2,5–4 с	больше 4 с
INP (Interaction to Next Paint)	Задержка между действием пользователя и реакцией страницы	до 200 мс	200–500 мс	больше 500 мс
CLS (Cumulative Layout Shift)	Насколько сдвигается вёрстка во время загрузки	до 0,1	0,1–0,25	больше 0,25

Пороговые значения опубликованы Google на web.dev. Оценивается 75-й перцентиль: страница проходит, если хорошие значения у трёх четвертей посещений. INP в 2024 году заменил прежнюю метрику FID и строже оценивает отзывчивость.

Где смотреть реальные данные, а не лабораторные?

Реальные данные смотрят в отчётах, собранных с посещений настоящих пользователей: Search Console, PageSpeed Insights в разделе полевых данных, отчёт Chrome UX Report или собственный сбор метрик на сайте. Лабораторная проверка в Lighthouse полезна для отладки, но не показывает, как сайт работает на медленных телефонах ваших посетителей.

Разница между ними:

• полевые данные — реальные устройства, сети и сценарии; обновляются с задержкой, нужен трафик;
• лабораторные данные — одна симуляция; удобны для проверки исправлений до выкладки;
• INP в лаборатории почти не измерить — он зависит от реальных действий пользователя.

Для собственного сбора подходит библиотека web-vitals от Google:

import { onLCP, onINP, onCLS } from 'web-vitals'

function send(metric) {
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    page: location.pathname,
  }))
}

onLCP(send)
onINP(send)
onCLS(send)

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

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

Что делать:

1. Отдавать главное изображение в современном формате (WebP или AVIF) и нужного размера для каждого экрана.
2. Не ставить ленивую загрузку на изображение первого экрана и добавить ему высокий приоритет загрузки.
3. Сократить время ответа сервера: кеширование страниц, CDN, быстрые запросы к базе — об этом в статье кеширование в веб-приложении.
4. Отдавать HTML с сервера, чтобы крупный элемент не ждал выполнения JavaScript.
5. Подключать критичные шрифты с предзагрузкой и font-display: swap.

Фото: Unsplash

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

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

Отзывчивость: INP

• уменьшить объём JavaScript: разделить код по страницам, убрать неиспользуемые библиотеки;
• разбивать долгие задачи на части, чтобы браузер успевал отвечать на клики;
• откладывать загрузку виджетов чатов, аналитики и рекламы до взаимодействия или простоя;
• не выполнять тяжёлые вычисления в обработчиках кликов и ввода.

Стабильность: CLS

• указывать размеры у изображений и видео (width и height или aspect-ratio);
• резервировать место под баннеры, рекламу и встраиваемые блоки;
• не вставлять содержимое над уже показанным, кроме как в ответ на действие пользователя;
• подбирать запасной шрифт, близкий по метрикам к основному, чтобы текст не прыгал при смене.

С чего начать оптимизацию?

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

Порядок работы:

1. Открыть отчёт Core Web Vitals в Search Console и найти группы страниц с плохими значениями.
2. Воспроизвести проблему в Lighthouse или инструментах разработчика на типичном шаблоне.
3. Исправить главную причину и проверить результат в лаборатории.
4. Выложить и дождаться обновления полевых данных — это занимает несколько недель.

Проверку скорости стоит включить и в общий чек-лист перед запуском — он собран в статье техническое SEO перед запуском сайта.

Коротко

• Core Web Vitals: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 у 75% посещений.
• Ориентируйтесь на полевые данные реальных пользователей, лабораторные — для отладки.
• LCP: лёгкое главное изображение без ленивой загрузки, быстрый сервер, HTML с сервера.
• INP: меньше JavaScript и отложенные сторонние скрипты; CLS: размеры у медиа и резерв места.
• Начинайте с самых посещаемых шаблонов и самой плохой метрики.