Core Web Vitals - это три метрики, которыми Google измеряет ощущение от загрузки и отзывчивости страницы. Они честно оценивают важные части опыта, но хороший балл сам по себе не делает содержимое релевантным. У той же карточки технической книги в мультиязычном магазине может быть идеальный результат в лаборатории и при этом ни одного ответа на запрос покупателя. Оптимизировать нужно реальное взаимодействие, а не только показатель теста.
Разберём, что измеряет каждая метрика. LCP (Largest Contentful Paint) фиксирует момент, когда становится видимым главное содержимое первого экрана - для карточки это обычно обложка книги и заголовок; хороший порог - 2,5 секунды. INP (Interaction to Next Paint) показывает, как быстро интерфейс визуально отвечает на действия пользователя - клик по кнопке купить, раскрытие описания; хороший порог - 200 миллисекунд. CLS (Cumulative Layout Shift) измеряет, насколько неожиданно смещается верстка, пока страница дозагружается; хороший порог - 0,1. Пороги берутся не по среднему, а по 75-му процентилю реальных загрузок: страница считается быстрой, только если так её видят три четверти пользователей, а не счастливое меньшинство на быстром канале.
| Метрика | Что измеряет | Хороший порог |
|---|---|---|
| LCP | когда виден главный элемент первого экрана | 2,5 с |
| INP | как быстро интерфейс отвечает на действие | 200 мс |
| CLS | насколько неожиданно смещается верстка | 0,1 |
Как это связано с поиском. Page experience, куда входят Core Web Vitals, - это ранжирующий сигнал, но слабый: он не перебивает релевантность. Между двумя одинаково полезными страницами поисковик предпочтёт более быструю, но медленная страница с точным ответом обойдёт быструю пустышку. Отсюда наивная ошибка - гнаться за цифрой 100 в отчёте, вместо того чтобы улучшать то, что реально чувствует человек. Page experience этим не исчерпывается: в ту же группу сигналов входят HTTPS и отсутствие навязчивых межстраничных баннеров, перекрывающих контент.
Чтобы не оптимизировать вслепую, различают два вида данных. Field data - это измерения у настоящих пользователей, собранные в CrUX и вашей системой RUM; именно они отражают опыт и учитываются в ранжировании. Lab data - это синтетический прогон в Lighthouse на фиксированном железе; он нужен, чтобы воспроизвести и продиагностировать проблему. Поле говорит что болит, лаборатория - почему. Важная тонкость: INP по определению меряется на живых кликах, поэтому в чистой лаборатории его толком не увидеть - она покажет потенциально долгие задачи, но настоящую цифру даст только поле. Сегментировать поле обязательно: по шаблону страницы, устройству, стране и типу соединения, - средняя температура прячет то, что карточка книги тормозит только на бюджетном Android в одной стране.
Отдельный рычаг - как страница рендерится. Если обложка, цена и заголовок приходят уже в серверном HTML, они видны сразу, и LCP наступает рано. Если тот же контент дорисовывает JavaScript после запроса к API, браузер сначала показывает пустой каркас, а робот ждёт рендера, - и LCP, и индексирование откладываются. Тот же выбор между сервером и клиентом, что решает судьбу индексации, определяет и скорость.
Провал выглядит буднично. В лаборатории у карточки 100 баллов, но в поле INP уходит за полсекунды: тяжёлый скрипт блокирует поток при первом клике по купить. А поздно подгруженный баннер с ценой сдвигает кнопку вниз в момент нажатия - высокий CLS, и покупатель промахивается. Ни то ни другое лабораторный балл не показал бы; увидеть это можно только в сегментированном поле. Платить за перформанс стоит там, где он мешает реальному действию, а не ради красивой цифры.