Core Web Vitals у Google Search Console: що показує звіт, пороги та як виправити

Звіт Core Web Vitals оцінює групи URL за трьома метриками реальних користувачів — LCP, INP і CLS — окремо для мобільних і компʼютерів. Група отримує статус найгіршої метрики, а звіту потрібно достатньо польових даних, щоб щось показати. Робочий порядок короткий: знайдіть пристрій і метрику, що провалилася, виправте її за відповідним посібником web.dev і натисніть «Почати відстеження». Звіт Google описує на своїй сторінці довідки.

Що читає звіт і пороги

Дані беруться зі звіту Chrome UX Report: польові дані реальних користувачів, а не лабораторний тест. URL групуються; група без достатньої кількості даних замінюється ширшою групою за джерелом, а за надто малого обсягу не показується нічого. Мобільні й компʼютери позначаються окремо.

Діапазони статусів такі. «Добре» — LCP не більше 2,5 секунди, INP не більше 200 мілісекунд і CLS не більше 0,1. «Потрібне поліпшення» — LCP до 4 секунд, INP до 500 мілісекунд і CLS до 0,25. «Погано» — усе, що вище. Статус групи визначається найслабшою її метрикою, тому відкрийте відомості про проблему, щоб побачити, яка з LCP, INP чи CLS не проходить і які групи URL зачеплено.

Як виправити метрику, що провалюється

Почніть із метрики, яку звіт позначає як провальну для найбільшої групи URL, оскільки статус іде за найгіршою. Для LCP пройдіть чотири складові часу завантаження, описані в посібнику web.dev щодо LCP. Для INP скоротіть затримку введення, обробку події та затримку відображення (оптимізація INP). Для CLS зарезервуйте місце для зображень, вбудувань, реклами й шрифтів, щоб нічого не стрибало під час завантаження (оптимізація CLS).

«Почати відстеження» і що означають 28 днів

Коли виправлення готове, натисніть «Почати відстеження». Це відкриває 28-денний сеанс моніторингу, і проблема вважається виправленою, лише якщо за ці 28 днів вона не зʼявилася на жодному URL. Тому не починайте, доки не виправлено всі випадки: будь-який URL із проблемою позначає всю проблему як невиправлену. «Почати відстеження» лише спостерігає; воно не запускає переіндексацію й не просить Google пересканувати.

Оскільки звіт використовує польові дані, виправлення проявиться лише після того, як буде записано достатньо реальних візитів, а швидкий лабораторний тест — не те саме, що вердикт звіту. Спершу виправте, потім відстежуйте й читайте статус після сеансу моніторингу, а не до нього.

Коли звіт порожній або URL відсутній

«Дані недоступні» означає, що ресурс новий або в Chrome UX Report замало даних для цього пристрою; після створення ресурсу може минути кілька днів, перш ніж зʼявляться наявні дані. Окремого URL може не бути, бо групі потрібні дані і за LCP, і за CLS та їхній мінімальний обсяг, з міркувань конфіденційності, інакше вона опускається. Звіт побудовано для сайту загалом, а не для пошуку статусу одного URL.

Це чинник ранжування?

Google пише, що добрі Core Web Vitals узгоджуються з тим, що прагнуть винагороджувати його основні системи ранжування (Core Web Vitals і Google Пошук). На його сторінці не сказано, яку вагу вони мають і як швидко проявиться зміна, тому вважайте 28 днів часом, протягом якого Google стежить за проблемою, а не обіцянкою зміни позицій.

Спостереження в SEOKit

У робочому просторі є звіт з історії Core Web Vitals на тих самих даних Chrome UX Report і тип сповіщення про регресії та відновлення, тому не треба відкривати Search Console, щоб дізнатися, що група просіла. Про інші звіти Search Console такого роду читайте в статті про звіти про якість сторінок і технічні звіти.

Читайте далі

Документація: сповіщення та webhooks: Налаштуйте сповіщення щодо Core Web Vitals. FAQ: статуси індексації сторінок: Інший великий технічний звіт.