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: статусы индексации страниц: Другой большой технический отчёт.