Core Web Vitals

Происхождение и история термина

Понятие ввела компания Google. Статья «Web Vitals» на портале web.dev, где описаны инициатива и её ядро, опубликована 4 мая 2020 года (автор — Филип Уолтон) ^[1]. 21 мая 2020 года вышла статья о том, как были выбраны пороговые значения метрик ^[4]. Web Vitals Google описывает как инициативу по единым рекомендациям о сигналах качества пользовательского опыта, а Core Web Vitals — как их подмножество, которое применимо ко всем страницам и должно измеряться всеми владельцами сайтов ^[1].

Исходный набор 2020 года состоял из LCP, FID (First Input Delay, задержка первого ввода) и CLS. Так его перечисляет публикация блога Google Developers Japan от 11 мая 2020 года — перевод поста Ильи Григорика «Introducing Web Vitals: essential metrics for a healthy site» из блога Chromium; там же сказано, что Core Web Vitals планируется обновлять ежегодно ^[18]. Затем состав и правила расчёта действительно менялись.

Таблица 1. Хронология Core Web Vitals

Замена FID на INP объясняется тем, что INP устраняет многие недостатки FID ^[5]. Если FID учитывал только задержку перед обработкой первого действия, то INP оценивает отзывчивость страницы на протяжении всего визита ^[6].

Для SEO в этой истории важнее всего связь Core Web Vitals с ранжированием в Google Поиске: Google относит их к аспектам удобства страницы (page experience) ^[2]. В официальном журнале обновлений ранжирования (Google Search Status Dashboard) зафиксировано обновление «Page experience update for desktop», начатое 22 февраля 2022 года ^[20]. Сегодня Google прямо пишет, что Core Web Vitals используются его ранжирующими системами ^[3].

Изменение CLS было менее заметным, но существенным: раньше метрика суммировала все отдельные сдвиги макета за время жизни страницы, теперь учитывается только самая большая «вспышка» сдвигов ^[8][9]. Поэтому значения CLS в старых материалах и в современных инструментах могут не совпадать.

Суть и механизм

Web Vitals и Core Web Vitals

Web Vitals — широкая программа Google, в которую входят и вспомогательные метрики. Core Web Vitals — только три метрики ядра ^[1]. Например, время до первого байта (TTFB) и первая отрисовка контента (FCP) помогают диагностировать проблемы с LCP, а общее время блокировки (TBT) — лабораторная метрика, помогающая найти причины плохого INP; в ядро они не входят ^[1]. Поэтому выражение «Google Web Vitals» не синоним Core Web Vitals: первое шире.

Три метрики ядра

LCP (Largest Contentful Paint, отрисовка крупнейшего содержимого) — метрика загрузки. Она фиксирует момент, когда в видимой области экрана отрисован самый крупный элемент: изображение, блок текста или видео ^[7]. Кандидатами считаются элементы <img>, <image> внутри <svg>, <video>, элементы с фоновым изображением, заданным через url(), и блочные элементы с текстом ^[7]. Подробнее — в статье LCP.

INP (Interaction to Next Paint, задержка до следующей отрисовки) — метрика отзывчивости. Учитываются клики мышью, касания сенсорного экрана и нажатия клавиш на физической или экранной клавиатуре; наведение курсора, масштабирование и прокрутка не учитываются ^[6]. Задержка каждого взаимодействия складывается из трёх фаз: задержки ввода (до запуска обработчиков), времени обработки (работа обработчиков) и задержки отображения (до показа следующего кадра) ^[6]. Обычно в качестве значения INP берётся самое медленное взаимодействие за визит, но на страницах с большим числом действий отбрасывается одно самое медленное взаимодействие на каждые 50 ^[6]. Подробнее — в статье INP.

CLS (Cumulative Layout Shift, совокупное смещение макета) — метрика визуальной стабильности: насколько неожиданно «прыгает» содержимое страницы. Для каждого сдвига вычисляется оценка по формуле «доля затронутой области экрана × доля расстояния смещения» (impact fraction × distance fraction) ^[8]. Сдвиги объединяются в окна сессии: промежуток между сдвигами меньше 1 секунды, общая длительность окна — не больше 5 секунд; значением CLS становится окно с наибольшей суммой ^[8]. Сдвиги, произошедшие в течение 500 мс после клика, касания или нажатия клавиши, помечаются как ожидаемые и могут исключаться из расчёта ^[8]. Подробнее — в статье CLS.

Модель оценки: 75-й процентиль

Core Web Vitals оценивают не одну загрузку, а распределение реальных визитов. Google рекомендует ориентироваться на 75-й процентиль, отдельно для мобильных устройств и компьютеров ^[1]. Процентиль означает: у 75 % загрузок значение метрики не хуже указанного ^[12]. Выбор объясняется двумя критериями: цель должна выполняться для большинства визитов, а итог не должен сильно зависеть от выбросов ^[4].

Пример: отсортируем 100 визитов на смартфонах по LCP от быстрых к медленным. Если самый медленный из 75 самых быстрых визитов загрузился за 2,3 с, это и есть значение на 75-м процентиле; оно не больше 2,5 с, поэтому по LCP страница в зоне «хорошо».

Как Google подбирал пороги

Пороги — компромисс двух требований: обеспечить качественный пользовательский опыт и оставаться достижимыми для существующих сайтов ^[4]. Для достижимости авторы требовали, чтобы порог «хорошо» выполняли как минимум 10 % источников (origins) в вебе ^[4]. Для CLS прямой научной базы не было: авторы прямо пишут, что не знают исследований, которые могли бы напрямую обосновать пороги этой новой метрики, и вместо этого оценивали реальные страницы с разным объёмом сдвигов ^[4].

Жизненный цикл метрик

Метрики проходят три стадии: экспериментальная, ожидающая (pending) и стабильная ^[1]. На стадии ожидания метрика остаётся не меньше шести месяцев, а стабильные метрики меняются не чаще раза в год ^[1]. Путь INP — пример этого цикла: эксперимент с мая 2022 года, объявление о переходе в мае 2023 года, стабильный статус с марта 2024 года ^[5].

Виды и классификации

Все классификации в этом разделе — классификации Google.

Пороговые значения

Таблица 2. Пороги Core Web Vitals (на 75-м процентиле)

Источники: ^{[4][6][7][8][14]}. Границы включаются в лучшую категорию: ровно 2,5 с, 200 мс и 0,1 — это ещё «хорошо», ровно 4 с, 500 мс и 0,25 — «требует улучшения» ^[6][14].

Названия статусов зависят от инструмента. В документации web.dev используются английские good / needs improvement / poor ^[6][7]; в русской Справке Search Console им соответствуют «Хорошо», «Нужно увеличить скорость» и «Низкая скорость» ^[14]. Варианты «требует улучшения» и «плохо» — описательный перевод.

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

Таблица 3. Полевые и лабораторные данные

Уровень оценки: страница и источник

CrUX собирает данные на уровне отдельных URL и на уровне источника (origin) — всего сайта ^[11]. Если у конкретной страницы данных недостаточно, PageSpeed Insights переходит к данным уровня источника (origin) ^[13], то есть к агрегированным данным CrUX по всем страницам сайта; в них входят только визиты, отвечающие критериям CrUX по браузеру, платформе и пользователю ^[11]. Search Console объединяет URL в группы страниц со сходным пользовательским опытом и присваивает статус группе ^[14].

Вспомогательные метрики вне ядра

TTFB и FCP — вспомогательные метрики загрузки; в CrUX API TTFB пока имеет экспериментальный статус (experimental_time_to_first_byte) ^[1][12]. TBT — лабораторная метрика; в ядро она не входит, потому что не измеряется в полевых условиях ^[1].

Как применяется на практике

Google Search

Позиция Google сформулирована на странице о page experience в документации Search Central: «Core Web Vitals are used by our ranking systems» («Core Web Vitals используются нашими ранжирующими системами») ^[3]. На той же странице: «There is no single signal» («Единого сигнала не существует») и «Google Search always seeks to show the most relevant content, even if the page experience is sub-par» («Google Поиск всегда стремится показать самый релевантный контент, даже если удобство страницы ниже среднего») ^[3]. Хорошие результаты в Search Console или сторонних инструментах, по словам Google, не гарантируют попадания страницы в верхние позиции ^[3]. Там же отмечено, что по многим запросам полезного контента много, и в таких случаях хорошее удобство страницы может способствовать успеху в Поиске ^[3].

В документе о Core Web Vitals Google «настоятельно рекомендует» владельцам сайтов добиваться хороших показателей и пишет, что это вместе с другими аспектами удобства страницы соответствует тому, что стремятся вознаградить основные ранжирующие системы ^[2]. Конкретного «веса» фактора Google не публикует, поэтому оценки вроде «CWV — главный фактор» не опираются на официальные данные. Подробнее о месте сигнала среди других — в статье Факторы ранжирования.

Россия: Яндекс и аналитика скорости

Подходы Google и Яндекса к скорости страниц различаются, и для российского сайта это важно.

Таблица 4. Google и Яндекс: метрики скорости страниц

Из таблицы следуют три практических вывода. Во-первых, отчёт Метрики «Время загрузки страниц» показывает этапы загрузки, а не LCP, INP и CLS ^[16], поэтому сравнивать его цифры с Core Web Vitals напрямую нельзя. Во-вторых, медиана и 75-й процентиль — разные статистики: медиана описывает «типичный» визит, а 75-й процентиль строже, он учитывает и более медленные визиты. В-третьих, CrUX собирает данные только от Chrome на компьютерах и Android; Chrome на iOS, WebView в приложениях Android и другие браузеры на Chromium (в документации пример — Microsoft Edge) в выборку не входят ^[11]. Значит, опыт посетителей, которые пользуются Яндекс Браузером, Safari или другими браузерами, в CrUX не отражён. Чтобы видеть Core Web Vitals всей аудитории, нужен собственный сбор полевых данных, например с помощью библиотеки web-vitals и отправки значений в свою систему аналитики ^[15]; подробнее — в статье Яндекс Метрика.

Типовые причины плохих значений

Медленный LCP может быть связан с долгим ответом сервера: по оценке Google, высокий TTFB может сделать достижение LCP 2,5 с трудным или даже невозможным ^[19]. Ещё одна причина — таблицы стилей и синхронные скрипты, которые блокируют отрисовку элемента LCP даже после загрузки его ресурса ^[19]; при этом время скачивания самого ресурса, по данным того же руководства, у большинства сайтов не главное «узкое место» ^[19]. Плохой INP связан с задержкой ввода из-за длинных задач в основном потоке ^[6]. Высокий CLS вызывают изображения и видео без заданных размеров, веб-шрифты, которые отрисовываются крупнее или мельче резервного шрифта, и контент, динамически вставляемый над уже показанным ^[8]. Подробнее о методах оптимизации — в статьях Скорость загрузки сайта, CDN, Рендеринг страниц и JavaScript SEO.

Пример: 95 баллов в Lighthouse, но оценка Core Web Vitals не пройдена

Условный пример. Владелец сайта проверяет мобильную версию страницы в PageSpeed Insights и видит два блока.

• Лабораторный блок (Lighthouse): Performance — 95 баллов. В PageSpeed Insights 90 баллов и выше считаются хорошим результатом ^[13].
• Полевой блок (CrUX, 28 дней): LCP — 2,1 с, CLS — 0,05, INP — 350 мс на 75-м процентиле. Вердикт — оценка Core Web Vitals не пройдена.

Противоречия здесь нет. Lighthouse загружает страницу один раз на одном смоделированном устройстве в фиксированных сетевых условиях ^[13] и не совершает действий пользователя, поэтому INP не измеряет и вместо него показывает TBT ^[1][6]. Реальные посетители кликают по меню, фильтрам и кнопкам, и на слабых смартфонах обработчики JavaScript работают медленно — это и видит INP. Полевые данные при наличии обоих видов данных приоритетны ^[10]. Бывает и обратная ситуация: низкий лабораторный балл при пройденной полевой оценке, например если реальные посетители в основном заходят с быстрых устройств ^[10].

Как измерить или проверить

Правило прохождения оценки

Страница или источник проходят оценку Core Web Vitals, если 75-е процентили всех трёх метрик находятся в зоне «хорошо»; если данных по INP недостаточно, оценка проходится при хороших LCP и CLS ^[13].

Инструменты

Таблица 5. Инструменты проверки Core Web Vitals

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

Чтобы страница попала в CrUX, она должна быть публично доступной по тем же критериям индексируемости, что и для поисковых систем, и достаточно популярной; точный порог популярности Google не раскрывает ^[11]. Пользователи тоже отбираются: в выборку попадают те, кто включил отправку статистики использования и синхронизацию истории браузера ^[11]. В Search Console данных может не быть, если ресурс добавлен недавно или о его работе на мобильных устройствах или компьютерах недостаточно сведений ^[14]. Для небольших сайтов это обычная ситуация, и тогда остаются лабораторные замеры и собственный сбор полевых данных.

Мини-инструмент на странице

Калькулятор на этой странице принимает три значения — LCP в секундах, INP в миллисекундах и CLS — и показывает статус по каждой метрике по таблице 2, а также общий вердикт: «пройдено», если все три значения не хуже порога «хорошо», иначе «не пройдено». Граничные значения 2,5 с, 200 мс и 0,1 считаются «хорошо», 4 с, 500 мс и 0,25 — «требует улучшения». Инструмент классифицирует введённые вами значения; он не измеряет сайт. Для реальных данных используйте PageSpeed Insights или Search Console.

Ошибки, ограничения и спорные вопросы

Балл Lighthouse — не оценка Core Web Vitals. Балл Performance строится на лабораторной загрузке, а вердикт Core Web Vitals — на полевых данных CrUX за 28 дней ^[13]. Высокий балл не гарантирует пройденной оценки, и наоборот ^[10].

Устаревшие материалы. Тексты, где ядро описано как «LCP, FID и CLS», написаны до 12 марта 2024 года; FID больше не входит в Core Web Vitals ^[5]. CLS в старых инструментах и статьях мог считаться как сумма всех сдвигов за время жизни страницы ^[8][9].

Две крайности в оценке влияния на позиции. Утверждение «Core Web Vitals — главный фактор ранжирования» противоречит позиции Google о приоритете релевантности ^[3]. Обратное утверждение «не влияет вовсе» противоречит прямому заявлению, что метрики используются ранжирующими системами ^[3]. Количественного веса сигнала Google не раскрывает.

Ограниченность выборки CrUX. Только Chrome на компьютерах и Android, только пользователи с включёнными статистикой и синхронизацией, только публичные и достаточно популярные страницы ^[11]. Для российской аудитории, где заметная часть посетителей может пользоваться другими браузерами, это смещение особенно ощутимо; точную долю можно оценить только по собственной аналитике сайта (вывод).

Задержка данных. CrUX — скользящее среднее за 28 дней ^[12], поэтому улучшение отражается в отчётах постепенно, а Search Console после исправления наблюдает за группой URL 28 дней ^[14].

Обоснованность порогов. Пороги — компромисс между качеством опыта и достижимостью, а для CLS прямой исследовательской базы при выборе порога не было ^[4]. Это аргумент против восприятия порогов как «научных констант»: это договорные ориентиры Google.

Строгие и нестрогие неравенства. В англоязычном документе Search Central пороги сформулированы как «less than 200 milliseconds» и «less than 0.1» ^[2], тогда как web.dev и Справка Search Console указывают «≤» ^[6][14]. Для классификации значений на границе опирайтесь на таблицу Search Console и web.dev: 200 мс и 0,1 — «хорошо».

Частые вопросы

Связанные термины

• LCP — LCP (Largest Contentful Paint)
• INP — INP (Interaction to Next Paint)
• CLS — CLS (Cumulative Layout Shift)
• Скорость загрузки сайта — Скорость загрузки сайта
• Google Search Console — Google Search Console
• Факторы ранжирования — Факторы ранжирования
• Mobile-first индексация — Mobile-first индексация
• Яндекс Метрика — Яндекс Метрика
• Рендеринг страниц — Рендеринг страниц
• SEO-аудит — SEO-аудит