RUM и полевое профилирование: лаборатория врёт, поле решает

Лаборатория врёт, поле решает

Прогон Lighthouse на вашей машине — одна выборка из распределения железа, в котором ваши пользователи не живут. Когда вы спорите с полевыми данными, прикрываясь Lighthouse-оценкой, — это именно та путаница, которую разбирает этот урок. CPU медианного пользовательского устройства в разы медленнее ноутбука разработчика; поле добавляет задушенные сети, телефоны с 4 ГБ RAM, режим энергосбережения, двадцать открытых вкладок, блокировщики рекламы и сессии по восемь часов вместо лабораторных девяноста секунд. Лабораторные инструменты (Lighthouse, WebPageTest, локальный Profiler) остаются необходимыми — они контролируемы, а значит, ловят регрессии до релиза на фиксированном устройстве и воспроизводят их детерминированно. Но они отвечают на вопрос «может ли это быть медленным?», и никогда — «медленно ли это у настоящих пользователей?». Полевые данные — Real User Monitoring (RUM, мониторинг реальных пользователей) — это та истина, на которой построена программа Core Web Vitals: Chrome агрегирует LCP, INP и CLS реальных сессий по origin, и проходной балл — p75 реальных просмотров страниц. Senior-команда использует оба мира и не путает их роли: лаборатория — пререлизный регрессионный гейт, поле — вердикт.

Подключение web-vitals: три измерения или шум

Библиотека web-vitals — стандартный инструмент: колбэки onLCP, onINP, onCLS срабатывают, когда метрика финализируется, — а для INP и CLS это поздняя стадия жизненного цикла страницы, поэтому отправка обязана сбрасываться на visibilitychange/pagehide через sendBeacon, а не на load. Сама проводка — двадцать строк; данные делают пригодными к действию измерения, которые вы прикрепляете:

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name,            // 'INP' | 'LCP' | 'CLS'
    value: metric.value,
    rating: metric.rating,        // 'good' | 'needs-improvement' | 'poor'
    route: routePattern(),        // измерение 1: '/orders/:id', НЕ сырой URL
    release: __RELEASE__,         // измерение 2: id сборки, внедрённый при деплое
    device: deviceClass(),        // измерение 3: грубая корзина: память + ядра
    attr: summarize(metric.attribution),
  }));
}
onINP(send); onLCP(send); onCLS(send);

Роут говорит, какая поверхность регрессировала, — глобальное число усредняет маркетинговую страницу с дата-гридом до бессмыслицы. Релиз превращает «когда-то стало медленно» в «кольцо N на 40% хуже кольца N−1» — вопрос о регрессировавшем релизе становится одним group-by. Класс устройства отделяет «мы выкатили регрессию» от «ретейл-кампания привела трафик с дешёвых Android» — сдвиг структуры трафика двигает глобальные перцентили без единого изменения кода. Отсутствие любого из трёх схлопывает разные популяции в среднее, неспособное отвечать на вопросы; это и есть трёхнедельная охота из вступления.

Атрибуция INP: куда ушли миллисекунды

INP — это примерно худшее взаимодействие просмотра страницы (для насыщенных страниц — высокий перцентиль всех взаимодействий, так что один плохой клик среди сотен всё равно считается). Attribution-сборка делит каждое взаимодействие-кандидат на три фазы, и это деление решает, где работать: задержка входа (input delay) — событие лежало в очереди, потому что главный поток был занят чем-то другим (гидрация, обновление чарта, сторонний скрипт); длительность обработки (processing) — выполнялись ваши обработчики, включая синхронный рендер и коммит React, который они запускают; задержка отрисовки (presentation) — кадр после обработчиков шёл долго (layout, paint, слишком много DOM). Атрибуция также называет целевой элемент и тип события. React-специфичное чтение: толстый слой processing на нажатиях клавиш — это обычно большой синхронный каскад рендера, и лечится он мемоизацией, виртуализацией списков или переносом обновления в transition. Толстая задержка входа на кликах сразу после навигации — это обычно гидрация или парсинг данных, оккупировавшие поток, и оптимизация обработчика там не даёт ничего. Обсерверы Long Tasks и более новый Long Animation Frames (PerformanceObserver с типом long-animation-frame) атрибутируют занятый поток конкретным скриптам, замыкая вопрос «занят чем?».

React Profiler в продакшене, по сэмплу

Колбэк onRender компонента Profiler отдаёт тайминги по коммитам: id, phase (mount/update), actualDuration (время рендера поддерева в этом коммите), baseDuration (оценка полного рендера без мемоизации). Продакшен-сборки по умолчанию вырезают профилирование; включение означает поставку profiling-сборки (react-dom/profiling) с накладными расходами в несколько процентов. Дисциплина, делающая это жизнеспособным: семплируйте сессии, а не коммиты — включайте профилирование примерно для 1% сессий, выбранных на старте сессии, отправляйте агрегированный actualDuration по id профайлера и тегируйте данные каждой сессии теми же тремя измерениями. Полная трассировка каждой сессии слишком тяжела дважды: рантайм-надбавка ложится ровно на те медленные устройства, которые вам важны, а объём маяков стоит дороже, чем даваемое им знание. Один процент от миллионов сессий даёт плотные перцентильные оценки по кольцам релиза — достаточно, чтобы увидеть, что коммиты OrdersTable стали в 3 раза медленнее в релизе 142, не профилируя ни одного лишнего пользователя.

Перцентили по кольцам, алерты по ущербу и граница приватности

Запрос, отвечающий «какой релиз регрессировал»: p75 INP по роуту, сгруппированный по кольцу релиза, кольцо к кольцу — канарейка на 1% даёт ответ до полного раската, если трафик пробивает минимальный размер выборки. Дизайн алертов следует одному принципу: будить из-за ущерба пользователям, а не из-за метрик. Алерт, достойный пейджера, — конъюнкция: p75 роута выше порога И держится N минут И трафик выше пола — потому что каждое условие поодиночке производит шум: перцентили на тонком трафике дико болтаются, мгновенные всплески самоизлечиваются, а один медленный синтетический проб — не инцидент. Мягкий дрейф (p75 ползёт на 5% в неделю) уходит в канал еженедельного ревью, а не в пейджер. И граница приватности не обсуждается: перф-маяки не несут никакого PII — паттерны роутов вместо сырых URL (квери-строки текут токенами и почтами), грубые корзины устройств вместо отпечатков, никаких id пользователей. Перф-маяк, способный идентифицировать пользователя, — это инцидент по защите данных, ждущий своего аудитора; проектируйте схему так, чтобы вопрос не возникал вовсе.