Трейдоффы метрик, RUM-атрибуция и цикл CI+поле

Команда фиксит LCP инлайнингом полного блока критического CSS — render delay LCP падает на 400 мс. Но TTFB растёт на 60 мс из-за того, что HTML теперь на 40 КБ больше. Другая команда lazy-load-ит каждую не-hero картинку для сокращения бандла — LCP остаётся нормальным, но hero случайно попал и LCP регрессирует на 800 мс. Ещё одна команда шипает полный SPA и получает зелёные vitals при первой загрузке — но каждый клиентский переход маршрута невидим для метрик. Один бюджет, три метрики, четыре команды и ни одной ручки.

Метрики — не независимые ручки.

Фикс одной Core Web Vital может навредить другой, и senior-ход — видеть систему, а не отдельные метрики. Частые трейдоффы:

• Инлайнинг большого блока критического CSS помогает render delay LCP (нет render-blocking запроса), но раздувает HTML, вредя TTFB. Итоговый эффект зависит от скорости соединения и размера HTML.
• Lazy-load всего для сокращения бандла помогает INP (меньше JS парсить и выполнять), но, применённый случайно к hero-картинке, добавляет большой load delay и рушит LCP.
• Резервирование щедрого места для CLS — большие min-height контейнеры для рекламы — может опустить LCP-элемент ниже сгиба, и он перестаёт быть LCP-кандидатом. Иногда это нормально; иногда нет.
• Отгрузка большого интерактивного фреймворка ради отзывчивого ощущения добавляет гидратацию — одну большую длинную задачу, взрывающую INP для ранних взаимодействий.

Единой ручки нет. Дисциплина: измерять все три до и после любого изменения, в поле где возможно, в throttled-лабе как минимум. Изменение, улучшающее одну метрику за счёт другой, может быть оправдано или нет — но знать это нельзя без взгляда на все три.

Атрибуция INP в поле: от метрики к строке кода.

Полевое число INP само по себе не actionable — это задержка без прикреплённой причины. Цепочка атрибуции:

1. PerformanceObserver, подписанный на event записи, даёт вам для каждого взаимодействия разбивку input delay / processing time / presentation delay.
2. Long Animation Frames (long-animation-frame записи через PerformanceObserver) дают для кадра, в который попало медленное взаимодействие, массив выполнившихся скриптов — с URL исходников, именами функций и длительностями.
3. Совмещайте: INP с высоким input-delay → найдите длинную задачу в записи LoAF; с высоким processing → обработчик, атрибутированный LoAF; с высоким presentation delay → тяжёлый рендер или принудительная синхронная компоновка в обработчике.

Весь смысл встройки LoAF в RUM — превратить «p75 INP 340 мс» в «функция фильтра поиска на search.js:88 — доминирующий скрипт в медленных кадрах». Это actionable.

Атрибуция LCP в поле.

Колбэк onLCP библиотеки web-vitals доставляет не только время LCP, но и элемент (чтобы знать, что браузер выбрал как LCP), URL ресурса (если картинка) и четырёхчастную разбивку: TTFB, load delay, load time, render delay. Логирование этого в телеметрию означает, что регрессия «LCP вырос с 1.9 с до 3.8 с» немедленно показывает, какая фаза выросла — был ли это TTFB (медленный деплой), load delay (случайный loading="lazy"), load time (неоптимизированная картинка) или render delay (новый render-blocking скрипт)?

Цикл RUM и CI — оба нужны.

Полный production-observability-стек состоит из двух половин.

RUM: отгрузить библиотеку web-vitals (или аналог), использующую PerformanceObserver для захвата LCP, INP и CLS ровно так, как Chrome их оценивает, плюс атрибуцию (элемент, разбивка фаз, цель взаимодействия, сдвигающиеся узлы). Отправлять в телеметрию с тегами маршрут, класс устройства, страна, релиз. Это реальный вердикт — ловит регрессии, которые лаб никогда не раскроет, особенно регрессии класса устройств и взаимодействия, которые запускают только реальные пользователи.

CI: синтетический гейт — Lighthouse CI или Playwright-трасса — на каждом PR, throttled под реалистичное mid-tier устройство, с бюджетами по LCP, total blocking time (lab-прокси для INP) и CLS, падающий на регрессии.

Ни одного в отдельности недостаточно. Лаб без RUM шипает регрессии, которые раскрывают только реальные устройства. RUM без CI-гейта означает, что каждая регрессия достигает production до того, как кто-то её замечает.

Разрыв soft-navigation — почему SPA-vitals требуют явной инструментации.

Core Web Vitals разрабатывались для полных загрузок страниц. В SPA первая загрузка имеет реальный LCP — но последующие клиентские переходы маршрутов («мягкие навигации») исторически не имели измерения LCP вообще, потому что не срабатывает событие document load. Для пользователя мягкая навигация ощущается ровно как загрузка страницы — он кликнул ссылку и ожидает быстрого нового контента — но метрика этого не видела.

Chrome шипает поддержку soft-navigation для атрибуции LCP и других vitals клиентским переходам маршрутов, но покрытие ещё созревает. Следствие: для SPA не предполагайте, что история vitals завершена только потому что числа первой загрузки зелёные. Быстрая первая загрузка + вялые переходы маршрутов — реальный, частый и исторически недоизмеренный провал. Инструментируйте мягкие навигации явно с PerformanceObserver soft-navigation записями или собственными RUM-марками на router.beforeEach / событиях смены маршрута.

[LCP] value: 4120 ms  rating: poor
element: img.hero
url: /assets/hero-original.jpg  (3.8 MB, JPEG, 4000x3000)
phase split: ttfb 280ms | loadDelay 90ms | loadTime 3510ms | renderDelay 240ms

[INP] value: 38 ms  rating: good
[CLS] value: 0.02  rating: good