Отчет Core Web Vitals

Полевые и лабораторные данные: две разные вещи

Лабораторный тест, например Lighthouse, один раз загружает страницу на эмуляции телефона среднего уровня с замедленным соединением. Его можно повторять сколько угодно, он полон подробностей, но посетитель, которого он описывает, воображаемый.

Полевые данные берутся из реальных посещений. Пользователи Chrome, согласившиеся делиться статистикой использования, отправляют анонимные замеры, а Google сводит их за последние 28 дней в Chrome UX Report, известный как CrUX. Именно эти данные Google Поиск читает, когда оценивает удобство страницы. Страница может набрать 95 в лаборатории и все равно провалиться в поле, потому что ее реальная аудитория сидит на старых телефонах. Бывает и наоборот: она проходит в поле со средним лабораторным результатом, потому что большинство посетителей приходят с заполненным кэшем.

Этот отчет сначала запрашивает полевые данные, потому что учитывается именно эта версия.

Пять показателей в таблице

Первые три и есть Core Web Vitals. FCP и TTFB показаны дополнительно, потому что помогают объяснить медленный LCP. На оценку они не влияют.

Как строится отчет

Мы проходим по перенаправлениям до конечного адреса, затем дважды запрашиваем CrUX: для телефонов и для компьютеров. Каждый запрос сначала пробует точную страницу, а если у самой страницы слишком мало трафика, переходит на весь источник (origin). Строка над каждой таблицей говорит, что именно вы читаете.

Для метрики показано значение 75-го процентиля: три посещения из четырех были как минимум настолько быстрыми. Цветная полоса рядом показывает долю посещений в диапазонах «хорошо», «требует улучшения» и «плохо».

Для оценки каждая из Core Web Vitals приносит 2 балла, если она хорошая, 1, если требует улучшения, и 0, если плохая. Шесть баллов из шести дают A, пять B, четыре C, три D, два E, меньше F. Одна плохая метрика ограничивает оценку уровнем D, какими бы хорошими ни были две другие. Главная оценка это оценка для телефонов, если данные по телефонам есть.

Когда у Chrome нет данных

CrUX охватывает только публичные страницы, которые посещают достаточно часто. Для всех остальных отчет запускает один тест PageSpeed Insights на эмуляции телефона и прямо об этом сообщает. Тогда вы получаете оценку производительности Lighthouse (A от 90, B от 75, C от 50, D от 35, E от 20), лабораторные значения LCP и CLS, а вместо INP показатель Total Blocking Time: отзывчивость на ввод невозможно измерить без человека, который этот ввод делает. Ниже перечислены до пяти проверок с наибольшей оценочной экономией времени.

Что влияет на каждую цифру

LCP

Найдите элемент LCP на панели Performance в Chrome DevTools. Обычно это главное изображение. Отдавайте его в отображаемом размере в WebP или AVIF, добавьте fetchpriority="high" и никогда не ставьте на него loading="lazy". Если TTFB уже больше 0.8 s, сначала исправьте сервер: кэширование страниц или CDN. Разбор размера страницы покажет самые тяжелые файлы.

INP

Длинные задачи JavaScript мешают странице реагировать на ввод. Уберите теги и плагины, которыми больше не пользуетесь, загружайте сторонние скрипты с defer и разбивайте работу, которая длится дольше 50 ms.

CLS

Задайте каждому изображению и видео атрибуты width и height, резервируйте место для рекламы и встроенных блоков с помощью min-height или aspect-ratio и не вставляйте баннеры над уже видимым содержимым.

Полевые данные собираются в скользящем окне длиной 28 дней. После исправления цифры понемногу улучшаются каждый день, а полный эффект виден через четыре недели. Посещения из Safari и из любого браузера на iPhone никогда не попадают в CrUX, поэтому отчет описывает только вашу аудиторию в Chrome.