Metric tradeoffs, RUM attribution, and the CI+field loop

A team fixes LCP by inlining the full critical CSS bundle — LCP render delay drops 400 ms. But TTFB rises 60 ms because the HTML is now 40 KB larger. A separate team lazy-loads every non-hero image to cut the bundle — LCP stays fine, but the hero was accidentally caught and LCP regresses 800 ms. Another team ships a full SPA and gets green vitals on the first load — but every client-side route change is invisible to the metrics. One budget, three metrics, four teams, and no single knob.

The metrics are not independent dials.

Fixing one Core Web Vital can hurt another, and the senior move is to see the system, not individual metrics. Common tradeoffs:

• Inlining a large critical CSS block helps LCP render delay (no render-blocking request) but bloats the HTML, hurting TTFB. The net effect depends on connection speed and HTML size.
• Lazy-loading everything to shrink the bundle helps INP (less JS to parse and execute) but, applied accidentally to the hero image, adds a large load delay and wrecks LCP.
• Reserving generous space for CLS — large min-height containers for ads — can push the LCP element below the fold so it is no longer the LCP candidate. Sometimes that is fine (the new LCP candidate is already fast). Sometimes it is not.
• Shipping a large interactive framework for a snappy feel adds hydration — one large long task that spikes INP for early interactions. The same feature simultaneously hurts INP and can hurt LCP (JS blocks the render-blocking parse path).

There is no single knob. The discipline: measure all three before and after any change, in the field where possible, in a throttled lab at minimum. A change that improves one metric at the cost of another may or may not be worth it — but you cannot know unless you look at all three.

INP attribution in the field: from metric to line of code.

A field INP number alone is not actionable — it is a latency with no cause attached. The attribution chain:

1. PerformanceObserver subscribed to event entries gives you, per interaction, the input delay / processing time / presentation delay split.
2. Long Animation Frames (long-animation-frame entries via PerformanceObserver) give you, for the frame where a slow interaction landed, the array of scripts that ran — with source URLs, function names, and durations.
3. Combine them: high input-delay INP → find the long task in the LoAF entry; high processing-time INP → the handler, attributed by LoAF; high presentation-delay INP → a heavy render or forced synchronous layout.

The whole point of wiring LoAF into RUM is to turn “p75 INP is 340 ms” into “the search filter function at search.js:88 is the dominant script in slow frames.” That is actionable.

LCP attribution in the field.

The web-vitals library’s onLCP callback delivers not just the LCP time but the element (so you know what the browser picked as LCP), the URL of the resource (if it is an image), and the four-phase breakdown: TTFB, load delay, load time, render delay. Logging these to telemetry means a regression from “LCP went from 1.9 s to 3.8 s” immediately surfaces which phase grew — was it TTFB (a slow deploy), load delay (an accidental loading="lazy"), load time (an unoptimised image), or render delay (a new render-blocking script)?

The RUM and CI loop — both halves required.

The complete production observability setup has two halves.

RUM: ship the web-vitals library (or equivalent), which uses PerformanceObserver to capture LCP, INP, and CLS exactly as Chrome scores them, plus attribution (element, phase split, interaction target, shifting nodes). Send them to telemetry tagged by route, device class, country, and release. This is the real verdict — it catches regressions a lab never will, especially device-class regressions and interactions that only real users trigger.

CI: a synthetic gate — Lighthouse CI or a Playwright trace — that runs on every PR, throttled to a realistic mid-tier device, asserting budgets on LCP, total blocking time (the lab proxy for INP), and CLS, and failing the build on a regression.

Neither alone is enough. Lab without RUM ships regressions that only real devices reveal. RUM without a lab gate means every regression reaches production before anyone sees it.

The soft-navigation gap — why SPA vitals need explicit instrumentation.

Core Web Vitals were designed around full page loads. In a single-page app, the first load has a real LCP — but subsequent client-side route changes (“soft navigations”) historically had no LCP measurement at all, because no document load event fires. To a user a soft navigation feels exactly like a page load — they clicked a link and expect new content fast — but the metric did not see it.

Chrome has been shipping soft-navigation support to attribute LCP and other vitals to client-side route changes, but coverage is still maturing and not all frameworks emit the right hints. The consequence: for a SPA, do not assume your vitals story is complete just because the initial-load numbers are green. Snappy first load + sluggish route transitions is a real, common, and historically under-measured failure. Instrument soft navigations explicitly with the PerformanceObserver soft-navigation entries or your own RUM marks on router.beforeEach / route change events.

[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