Полевые и лабораторные данные Core Web Vitals: CrUX, Lighthouse, RUM
Продвинутое3 минРедакция Innovialabs
Коротко
Lighthouse измеряет одну загрузку в искусственных условиях, а Search Console показывает данные реальных пользователей Chrome за 28 дней по 75-му перцентилю, поэтому цифры расходятся; для отслеживания исправлений нужен собственный RUM.
Почему цифры не совпадают
Лабораторные данные (Lighthouse, PageSpeed Insights в разделе диагностики) — это одна загрузка страницы на эмулированном устройстве с заданной скоростью сети. Полевые данные (CrUX, Search Console) — это то, что реально испытали пользователи Chrome на своих устройствах и сетях.
Они расходятся по нескольким причинам:
- Разные устройства и сети. У реальных пользователей бывают и мощные смартфоны с быстрым интернетом, и старые телефоны с медленной сетью.
- Кэш и повторные визиты. Лаборатория обычно грузит страницу «с нуля», а реальные посетители часто приходят с кэшем.
- Поведение. Лаборатория не кликает, не скроллит и не ждёт — а сдвиги макета и задержки реакции часто возникают именно при взаимодействии.
- INP не измеряется в лаборатории. Interaction to Next Paint требует реальных взаимодействий; Lighthouse показывает лишь косвенный показатель Total Blocking Time.
Для ранжирования поисковик опирается на полевые данные. Лабораторные нужны для отладки.
Как работает CrUX
Chrome UX Report (CrUX) — публичный набор данных о производительности, собранный у пользователей Chrome, которые разрешили отправку статистики.
- Скользящее окно 28 дней. Каждый день в отчёт добавляется новый день и уходит самый старый. Поэтому после исправления результат в Search Console меняется постепенно, а не сразу.
- 75-й перцентиль. Страница считается «хорошей», если показатель укладывается в порог хотя бы у 75% визитов.
- Порог трафика. Если у страницы недостаточно данных, CrUX показывает данные по всему источнику (origin) или не показывает ничего.
- Группировка в Search Console. Отчёт объединяет похожие URL в группы, поэтому проблема одного шаблона затрагивает сразу много страниц.
Сравнение источников
| Источник | Тип | Что даёт | Ограничения |
|---|---|---|---|
| Lighthouse | Лаборатория | Причины проблем, воспроизводимость | Одна загрузка, нет INP |
| PageSpeed Insights | Поле + лаборатория | Быстрый срез CrUX и диагностика | Нужен достаточный трафик |
| Search Console | Поле (CrUX) | Группы URL, статус для поиска | Задержка 28 дней, без деталей |
| Собственный RUM | Поле | Все страницы, сегменты, быстрая обратная связь | Нужно внедрять и хранить данные |
Как настроить RUM
Real User Monitoring — сбор метрик прямо в браузерах ваших посетителей. Он показывает эффект исправлений за дни, а не ждёт 28-дневное окно.
Самый простой путь — библиотека web-vitals от команды Chrome:
import { onLCP, onINP, onCLS } from 'web-vitals';
function send(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
page: location.pathname,
});
navigator.sendBeacon('/api/vitals', body);
}
onLCP(send);
onINP(send);
onCLS(send);
Дальше:
- Сохраняйте данные в аналитике или своей базе вместе с типом страницы, устройством и типом соединения.
- Считайте 75-й перцентиль, а не среднее — так вы смотрите на метрику так же, как CrUX.
- Сегментируйте по шаблонам страниц и мобильным/десктопным устройствам.
- Отмечайте релизы на графике, чтобы видеть эффект каждого изменения.
- Используйте атрибуцию (сборка
web-vitals/attribution), чтобы понять, какой элемент стал LCP или какое взаимодействие дало плохой INP.
Рабочий процесс исправлений
- Найдите проблемную группу URL в Search Console.
- Подтвердите проблему и сегмент в RUM.
- Воспроизведите и найдите причину в Lighthouse и DevTools.
- Выкатите исправление и проверьте RUM через несколько дней.
- Дождитесь обновления CrUX и нажмите «Проверить исправление» в Search Console.
Частые ошибки
- Оптимизировать «до 100 в Lighthouse», игнорируя полевые данные.
- Ждать изменений в Search Console на следующий день после релиза.
- Смотреть только на десктоп, когда основной трафик мобильный.