Core Web Vitals: что действительно важно измерять
Core Web Vitals часто воспринимают как экзамен, где нужно получить зелёный значок. Но метрики полезнее рассматривать как язык для разговора о пользовательском опыте. Они помогают различать медленное появление содержания, задержку реакции и скачки интерфейса. Разбираемся, как превратить аббревиатуры в понятные вопросы к сайту и не подменить реальную работу погоней за одной цифрой.
Евгений Порывкин
Веб-разработчик
Три разных вопроса к интерфейсу
LCP описывает время появления крупнейшего видимого элемента содержимого. INP характеризует задержку реакции на взаимодействия. CLS оценивает неожиданные сдвиги элементов. Хорошие ориентиры — LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Оценка прохождения применяется к 75-му процентилю и всем трём метрикам. Определения и пороги Google.
Представьте страницу записи на встречу. Заголовок и фотография появляются поздно — исследуем загрузку. Кнопка долго не реагирует — смотрим обработку взаимодействия. Перед нажатием форма уезжает вниз — разбираемся со стабильностью расположения. Внешне всё называется «тормозит», но задачи различаются.
Не смешивайте лабораторию и реальных посетителей
Лабораторный запуск проходит в определённых условиях. Полевые данные отражают опыт посетителей с разными устройствами, сетями и действиями. Эти источники дополняют друг друга, а не обязаны показывать одинаковый результат. Обычный запуск Lighthouse без взаимодействий не измеряет INP; вместо него может использоваться диагностический показатель TBT. Различия методов измерения.
Для команды полезно договориться, какой вопрос решает каждый отчёт. Лаборатория помогает воспроизвести проблему и проверить изменение. Данные аудитории показывают, насколько наблюдение характерно для реального использования. Отсутствие достаточной полевой статистики — не доказательство идеальной работы сайта.
Сравнивайте сопоставимые страницы
Не делайте вывод обо всём проекте только по главной. Карточка товара, длинная статья и личный кабинет устроены по-разному. Выберите типичные страницы каждого важного шаблона и запишите, что на них делает посетитель. Такой список одновременно станет основой проверки будущих релизов.
Отдельно смотрите мобильный и настольный сценарии. Список карточек может оставаться удобным на большом мониторе, но создавать совсем другие ограничения на телефоне. В задаче для разработчика должны быть адрес, условия и конкретное наблюдение, а не просьба «исправить красную метрику».
Переводите показатель в проверяемую гипотезу
Если проблема связана с появлением содержания, изучите последовательность загрузки. Если с взаимодействием — воспроизведите действие, после которого интерфейс замирает. Для сдвигов запишите видео или последовательно проверьте элементы, которые появляются позже остальных.
Не начинайте с заранее выбранного рецепта. Замена формата изображений не объяснит задержку из-за тяжёлой обработки клика. Увеличение мощности сервера не исправит отсутствие зарезервированного места под баннер. Хорошая гипотеза связывает наблюдение, предполагаемую причину и способ проверки.
Договоритесь, когда улучшение достаточно
Для каждой задачи фиксируйте исходную точку, изменение и повторный результат. Не обещайте универсальный эффект до проверки. Если вместе с ускорением ухудшился важный сценарий, например перестала работать форма, такую оптимизацию нельзя считать завершённой.
Метрики стоит включить в обычную приёмку проекта, но не делать единственным критерием. Читаемость, понятные ошибки, корректность данных и доступность действий остаются важными даже при хороших показателях. Зелёная оценка не проверяет смысл предложения и не гарантирует продажи.
Сделайте измерение привычкой
Выберите небольшой набор контрольных страниц и повторяйте проверку после заметных изменений. Храните результаты вместе с описанием релиза. Тогда ухудшение можно связать с конкретным событием, а не пытаться восстановить историю по памяти нескольких участников.
На встрече обсуждайте не только числа, но и следующий шаг. Например: проверить загрузку первого изображения, воспроизвести задержку фильтра, зарезервировать место для блока. Core Web Vitals становятся полезными именно в этот момент — когда помогают команде выбрать понятное действие.
Представьте еженедельную встречу по развитию сайта. Вместо общего сообщения «производительность плохая» принесите наблюдение: после выбора фильтра на мобильном устройстве список надолго перестаёт отвечать, а на странице статьи такого поведения нет. Укажите условия, приложите запись и предложите воспроизвести действие. Теперь у команды есть конкретная точка входа. Даже до выбора технического решения понятно, что исследовать первым, кого привлечь и как проверить исправление. Такой формат обсуждения бережёт время и не заставляет участников спорить о цифре, смысл которой каждый понимает по-своему.