Три метрики описывают разные ощущения пользователя
LCP измеряет, когда появился основной заметный контент. INP показывает, насколько быстро страница реагирует на клики, касания и клавиатуру. CLS оценивает неожиданные сдвиги элементов. Быстрая загрузка не компенсирует зависшую форму, а отзывчивость не компенсирует прыгающую кнопку.
Метрики являются нижней общей системой контроля, а не полным описанием опыта. Время отправки заявки или поиска по каталогу тоже должно измеряться отдельно.
Пороговые значения и 75-й процентиль
| Метрика | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|
| LCP | ≤ 2,5 с | 2,5–4,0 с | > 4,0 с |
| INP | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
75-й процентиль означает, что не менее 75% посещений должны укладываться в хороший порог. Среднее может скрыть плохой опыт значимой части аудитории.
Лабораторные и полевые данные не заменяют друг друга
Лабораторный тест запускается в контролируемом профиле и помогает повторять диагностику. Он показывает сетевой водопад, блокирующие ресурсы и длинные задачи. Полевые данные собираются у реальных посетителей с разными устройствами и сетями.
До запуска полевых данных нового URL нет. Приёмка использует лабораторный бюджет, а договор поддержки описывает сбор и реакцию на полевые показатели после накопления достаточного объёма.
Почему нельзя тестировать только главную
Шаблоны отличаются. Карточка имеет галерею, статья длинную типографику, каталог фильтры, форма стороннюю защиту. Составьте набор репрезентативных URL и измеряйте каждый при значимом релизе.
- Главная.
- Коммерческая услуга.
- Список и карточка.
- Статья.
- Поиск или фильтр.
- Форма или калькулятор.
Диагностика медленного LCP
Разделите время на серверный ответ, обнаружение ресурса, загрузку и отрисовку. Если LCP является изображением, укажите размеры, используйте подходящий формат и размер, не делайте его ленивым без причины и обеспечьте раннее обнаружение. Если это текст, проверьте шрифты и блокирующие стили.
Медленный TTFB может указывать на сервер, базу, отсутствие кеша или удалённый backend. Оптимизация картинки не исправит двухсекундный ответ HTML.
Диагностика плохого INP
INP ухудшают длинные задачи JavaScript, тяжёлая перерисовка, большие DOM-деревья и обработчики, выполняющие слишком много работы. Разделяйте задачи, уменьшайте клиентский код и давайте мгновенную обратную связь.
Проверьте реальные действия: открыть меню, применить фильтр, ввести текст, отправить форму. Лабораторный Lighthouse не всегда воспроизводит все взаимодействия, поэтому используйте профилирование и полевые события.
Диагностика CLS
Изображения и iframe получают размеры или резерв места. Баннер согласия, уведомление и форма не должны неожиданно сдвигать контент. Шрифты выбираются с учётом замены и метрик. Динамический блок вставляется в заранее зарезервированную область.
Сдвиг после действия пользователя иногда допустим, но неожиданный прыжок во время чтения или попытки нажать кнопку является проблемой.
Бюджет производительности
| Ограничение | Пример правила | Зачем |
|---|---|---|
| JavaScript | Лимит на первоначальный код шаблона | Снижает блокировку и INP |
| Изображения | Размеры и форматы по компоненту | Защищает LCP и трафик |
| Шрифты | Минимум начертаний и preload только критичного | Ускоряет текст и снижает сдвиг |
| Сторонние скрипты | Владелец и причина каждого | Контролирует непредсказуемый код |
| Сервер | Цель TTFB в тестовом регионе | Отделяет backend от frontend |
Модельный разбор карточки каталога
Карточка показывает LCP 4,1 секунды, INP 170 мс и CLS 0,04. Проблема сосредоточена в загрузке: сервер отвечает 1,2 секунды, hero-изображение весит 1,8 МБ и обнаруживается поздно внутри галереи. Команда оптимизирует запрос, кеширует данные, отдаёт адаптивное изображение и повышает приоритет первого кадра.
После изменений лабораторный LCP снижается до 2,2 секунды. Это ещё не доказательство полевого результата. После запуска команда следит за 75-м процентилем и сегментирует по шаблону и устройству.
Что включить в приёмку
- Список URL и условия теста.
- Несколько повторов, а не один удачный запуск.
- Пороговые Core Web Vitals.
- Диагностические метрики и водопад.
- Перечень сторонних скриптов.
- План полевого мониторинга.
- Правила реакции на регресс.
Нельзя гарантировать одинаковое время каждому пользователю: влияют устройство, сеть, география и внешние сервисы. Можно гарантировать метод измерения, бюджет реализации и устранение обнаруженного регресса в согласованных границах.