Проверка Core Web Vitals: метрики скорости, которые учитывает поиск

Что именно показывает проверка Core Web Vitals

Проверка core web vitals отвечает на более узкий вопрос, чем обычный тест скорости: укладывается ли страница в рекомендованные поисковой системой пороги качества при реальных посещениях. Низкое время полной загрузки само по себе не означает прохождение проверки. Страница может быстро получить все файлы, но поздно показать крупный заголовок, сместить форму после появления баннера или задержать реакцию кнопки из-за выполнения JavaScript.

Для итоговой оценки используются три метрики. Largest Contentful Paint фиксирует момент отрисовки крупнейшего видимого элемента содержимого. Cumulative Layout Shift суммирует неожиданные смещения элементов. Interaction to Next Paint оценивает задержку между пользовательским действием и следующим визуальным обновлением.

Страница проходит Core Web Vitals, когда все три показателя находятся в хорошей зоне на 75-м процентиле посещений. Иными словами, ориентироваться нужно не на лучший запуск теста, а на значение, в которое укладываются как минимум 75% наблюдений. Пороговая методика описана в документации web.dev.

Полевые и лабораторные данные: почему результаты различаются

Полевые данные собираются по реальным посещениям пользователей Chrome, которые отвечают условиям включения в Chrome User Experience Report. Они отражают разные устройства, сети, географию, состояние кеша и характер взаимодействия. Именно этот тип данных нужен для вывода о прохождении порогов.

Лабораторный тест выполняется в заданных условиях на одном устройстве или в эмуляции. Он полезен для воспроизведения проблемы и сравнения изменений, но является единичным наблюдением. В лаборатории обычно доступен LCP и CLS, а полноценный INP измерить нельзя: для него нужна последовательность реальных взаимодействий. В качестве диагностического приближения инструменты могут показывать другие показатели отзывчивости, но подменять ими полевой INP нельзя.

Диагностический алгоритм

1. Зафиксировать проверяемый URL

Проверяйте канонический публичный адрес с нужным протоколом, поддоменом и завершающим слешем. Редирект, мобильный поддомен и разные URL-параметры могут привести к анализу другой страницы или к агрегации данных не на том уровне.

2. Начать с полевого отчёта

Введите URL в PageSpeed Insights и найдите блок с опытом реальных пользователей. Уточните, к чему относится результат: к конкретному URL или ко всему источнику. Во втором случае данные характеризуют группу страниц домена, а не доказывают состояние выбранного документа.

3. Разделить мобильные и десктопные результаты

Не объединяйте платформы в среднее значение. На мобильных устройствах слабее процессоры и нестабильнее соединение; на десктопе отличаются экран, сценарии взаимодействия и набор загружаемых элементов. Для каждой платформы нужен самостоятельный вывод.

4. Проверить все три порога

Итог определяется худшей метрикой. Например, LCP 2,1 секунды и CLS 0,06 не компенсируют INP 280 миллисекунд: общий статус остаётся «нужны улучшения». Запишите значение, категорию, платформу, уровень агрегации и дату проверки — без этого сравнение следующих замеров будет неоднозначным.

5. Использовать лабораторный запуск для локализации

Если не проходит LCP, определите, какой элемент назначен крупнейшим: изображение, текстовый блок, постер видео или фон. При проблеме CLS просмотрите последовательность смещений. Для INP исследуйте взаимодействия с меню, фильтрами, формами и другими элементами в Chrome DevTools, обращая внимание на длительные задачи основного потока.

6. Проверить тенденцию, а не один снимок

Полевой набор меняется постепенно и отражает скользящий период наблюдений. После изменения страницы лабораторный результат может улучшиться сразу, а полевой — позднее. Сопоставляйте одинаковые URL, платформы и источники данных, не делая вывод по одному удачному запуску.

Контрольный чек-лист результата

• Проверен именно публичный канонический URL, а не адрес тестового стенда.
• Отдельно рассмотрены мобильные и десктопные пользователи.
• Указано, являются данные полевыми или лабораторными.
• Понятно, относятся наблюдения к URL или ко всему источнику.
• LCP не превышает 2,5 секунды на 75-м процентиле.
• INP не превышает 200 миллисекунд на 75-м процентиле.
• CLS не превышает 0,1 на 75-м процентиле.
• Общий статус признан хорошим только при прохождении всех трёх критериев.
• Для повторного измерения сохранены дата, платформа и значения метрик.

Типовые ошибки интерпретации

Считать оценку Lighthouse итогом Core Web Vitals. Балл производительности объединяет несколько лабораторных показателей по собственной формуле. Даже зелёный балл не заменяет полевые LCP, CLS и INP.

Сравнивать среднее значение с порогом. Официальная классификация опирается на 75-й процентиль. Среднее способно скрыть заметную долю медленных или нестабильных посещений.

Игнорировать область данных. Хорошие показатели источника не доказывают, что конкретный шаблон проходит проверку. И наоборот, одна тяжёлая страница не обязательно характеризует весь сайт.

Путать INP с задержкой первого действия. INP рассматривает взаимодействия в течение визита и близок к худшему наблюдаемому результату с поправками для страниц с большим числом действий. Это не только первый клик.

Ожидать гарантированного роста позиций. Google указывает, что Core Web Vitals используются системами ранжирования, но хорошие показатели не гарантируют верхних позиций. Релевантность и качество содержания остаются самостоятельными факторами. Это ограничение прямо отмечено в документации Google Search Central.

Границы метода

Core Web Vitals не являются полной проверкой скорости и не объясняют автоматически первопричину отклонения. Они не оценивают все сетевые этапы, доступность интерфейса, корректность разметки, безопасность, содержание страницы или удобство конкретного бизнес-сценария. Также метрики не заменяют анализ серверного ответа, водопада запросов и выполнения кода, когда требуется инженерная локализация.

Результат зависит от реального состава аудитории. Два технически одинаковых шаблона могут получить разные полевые значения из-за устройств, сетей, контента и способов взаимодействия. Поэтому порог — это критерий классификации наблюдаемого опыта, а не универсальная характеристика качества исходного кода.

Итог

Корректная проверка строится в два этапа: полевые данные отвечают, проходит ли страница установленные пороги, а лабораторная диагностика помогает найти воспроизводимый источник отклонения. Хороший статус требует одновременно LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1 на 75-м процентиле отдельно для рассматриваемой платформы.

Если полевых наблюдений мало, зафиксируйте это как ограничение, а не как успешный результат. Используйте лабораторный тест для предварительной оценки и возвращайтесь к полевому отчёту после накопления данных.