Observability в проде: LoAF, INP и полная поверхность атаки

Ваша страница набирает 95 в Lighthouse в офисе. На Pixel 4a пользователя в Джакарте с 3G-троттлингом INP — 340 мс. Это два разных измерения двух разных вещей. Только одно из них важно.

LoAF и INP: два взаимодополняющих сигнала

PerformanceLongAnimationFrameTiming (LoAF, поставлено в Chromium в 2023–2024) сообщает о каждом кадре длиннее 50 мс с разбивкой того, что доминировало: время рендеринга, блокирующий JS, форсированная компоновка. Это диагностический инструмент — говорит что работало долго, а не что почувствовал пользователь.

INP (Interaction to Next Paint) измеряет время от пользовательского input-события (клик, клавиша, тап) до следующего paint, видимо реагирующего. INP стал Core Web Vital в марте 2024, заменив FID. Плохой INP (>200 мс p75) почти всегда восходит к одной из двух проблем пайплайна:

1. Длинная JS-задача в input-обработчике, откладывающая rAF
2. Форсированная синхронная компоновка от чтения геометрии внутри обработчика

LoAF даёт данные для атрибуции в продакшене; INP даёт метрику, которую чувствует пользователь. Вместе они замыкают петлю от продовой телеметрии к конкретным диагностикам пайплайна.

Скролл вне главного потока

Браузеры поставляют скролл на потоке compositor последнее десятилетие: когда пользователь скроллит обычную страницу, compositor транслирует viewport на GPU без касания главного потока. Страница может скроллить плавно даже пока идёт долгая JS-задача.

Подводный камень: любой элемент с JS scroll-обработчиком, подключённым не-passively (без {passive: true}), заставляет браузер откатиться на скролл главного потока, потому что обработчик может вызвать preventDefault(). Всегда передавайте passive: true слушателям scroll, wheel и touchmove, если только вам действительно не нужен preventDefault. Современные браузеры предупреждают в DevTools, когда non-passive слушатель задерживает скролл.

Display locking и content-visibility

Механизм за content-visibility: auto — «display locking»: браузер приостанавливает рендеринг заблокированного поддерева (без пересчёта стилей, без компоновки, без отрисовки) и заменяет его placeholder intrinsic-size. Когда поддерево пересекает viewport через внутренний IntersectionObserver браузера, оно разблокируется и рендерится.

Числа: таблица из 10 000 строк, ранее стоившая 1 200 мс style + layout, рендерится за ~10 мс с content-visibility: auto.

Компромисс: скролл в ранее заблокированную область кратко останавливается для рендеринга. Если строки дорогостоящие, виден однокадровый рывок на границе разблокировки. Пары с contain-intrinsic-size даёте браузеру реалистичный placeholder-размер, чтобы позиция скролла не прыгала.

Reduced-motion как клапан бюджета рендеринга

@media (prefers-reduced-motion: reduce) устанавливается пользователями, испытывающими укачивание или желающими снизить энергопотребление. Помимо доступности, это клапан бюджета рендеринга: любую compositor-управляемую анимацию можно заменить мгновенным изменением состояния при reduced-motion, освобождая compositor от покадровой работы. Пользователи с ограниченным зарядом на бюджетном Android-телефоне получают значимую экономию батареи.

Web Workers и разгрузка главного потока

Когда главный поток достигает потолка, единственный способ снизить его — перенести работу. Web Workers выполняют JS в отдельном потоке без доступа к DOM; сериализация через postMessage стоит ~1 мс/МБ, что оправдано для CPU-тяжёлых задач (парсинг большого JSON, сжатие, криптография, обработка разметки).

OffscreenCanvas даёт прямой доступ к canvas API из воркера, полностью обходя главный поток. SharedArrayBuffer + Atomics предоставляют примитивы синхронизации между потоками для высокочастотных данных (аудио, потоки сенсоров реального времени). Стоимость входа высока (structured cloning, архитектура передачи сообщений), но потолок производительности пропорционально выше: четырёхъядерный телефон с занятым главным потоком всё ещё имеет 3 незадействованных ядра, которые большинство приложений никогда не используют.

Service Worker и пайплайн первой отрисовки

Service Workers не часть пайплайна рендеринга, но критически влияют на его входные данные. Service Worker, отвечающий на запросы из кэша (cache-first для статических ресурсов, network-first для API), доставляет первую отрисовку за 50 мс на повторных посещениях вместо 500 мс — 4 кадра против 30 при 60 fps.

Ключевое ограничение: скрипт Service Worker работает в отдельном потоке, но его запуск (когда он перехватывает первый запрос) имеет небольшую латентность. Держите Service Worker тонким и быстрым; 200-мс запуск при перехвате fetch задерживает первый HTML-байт и весь пайплайн парсинга вместе с ним.

Performance CI: перехват регрессий до мерджа

Бюджеты удерживаются, только когда регрессии перехватываются до мерджа. Реалистичный CI-пайплайн имеет три уровня:

1. Lighthouse CI в headless Chrome на каждом PR — ограничивает по абсолютным метрикам (LCP < 2.5 с, INP < 200 мс, CLS < 0.1), блокирует мердж при регрессии.
2. Синтетические бенчмарки на критических сценариях (открыть страницу, проскроллить список 1000×, нажать 5 кнопок) — измеряет p95 длительности кадра и p95 LoAF, сравнивает с baseline-веткой.
3. RUM (мониторинг реальных пользователей) в продакшене — отправляет перцентили INP, LCP, CLS в Datadog или подобное, алертит когда p75 INP пересекает 200 мс на любом сегменте пользователей (страна, устройство, версия приложения).

Без всех трёх уровней регрессия рендеринга попадает в продакшен, живёт там тихо месяцами и обнаруживается, когда жалоба пользователя заставляет кого-то смотреть.

Профилирование на реальном железе vs DevTools-троттлинг. «4-кратное замедление CPU» в DevTools Performance — приближение, не замена реального железа. M2 MacBook при 4-кратном замедлении всё равно имеет другую модель памяти, другой GPU и другой профиль теплового троттлинга, чем Pixel 6a. Профилируйте на физическом среднеценовом Android хотя бы раз в неделю с помощью Chrome для Android + удалённая отладка, и сравнивайте длительности кадров. Разница >30% означает мобильную регрессию, невидимую на десктопе.