web.dev: Web Vitals - discussion (2023-02-11)

We log vitals in-app, but only with context: route, posture, and a reason string.

Raw numbers without context are just a leaderboard, not a debugging tool.

We use a very small sample and emit a contract line so we can correlate spikes:

txt
[tips] vitals route=/dashboard lcp=2.3s inp=160ms cls=0.02 posture=warm cacheLane=cache
[tips] vitals route=/dashboard lcp=3.8s inp=420ms cls=0.10 posture=hot cacheLane=bypass reason=freshnessSwitch

The reason field turns the number into a story. Without it, it's just anxiety.

Counterpoint: in-app vitals logging can distort results and create privacy concerns if people get sloppy.

We prefer external tooling, and we only keep minimal in-app evidence (posture + freshness) for support/debugging.

Rendering posture evidence helped us more than logging vitals.

If a screenshot shows posture=hot and cacheLane=bypass, you already have half the perf explanation.

Long-form: web vitals are useful because they force you to define what "good" is.

Once you define it, you can encode it as a budget contract and have meaningful conversations about tradeoffs.

Without budgets, performance discussions are just preferences disguised as facts.

INP issues often came from too much work per tick. We introduced a tick posture (warm/cool) and logged it:

txt
[tips] tick=warm windowMs=5000 reason=default
[tips] tick=cool windowMs=15000 reason=batterySaver

Counterpoint: you can chase vitals and hurt correctness (stale data, weird caching).

We encoded the tradeoff as posture and made it visible. If you choose perf over freshness, the UI should say so.

CLS improved when we stabilized derived outputs. Reserving space and keeping derived shapes stable mattered more than micro-optimizing render.

Derived state isn't just speed; it's layout stability.

Long-form counterpoint: perf logs can become a substitute for simplifying the app.

We used the vitals story to justify deleting complexity. That ended up being the biggest improvement.

Docs tie-in: budgets + posture are a recurring theme in the perf docs.

Related: Performance and Rendering (Best Practices) and The App Router Mindset.

We added a single debug badge: perfPosture=warm and renderBudget=medium.

It prevented perf bug reports that didn't mention the mode the user was in.

Long-form: the reason to care about vitals isn't ranking, it's user trust.

If the page feels stable and responsive, users forgive a lot. If it janks, they assume the app is unreliable even when data is correct.

We treat perf posture changes like any other contract change: log it and render evidence.

If perf changes and you can't explain why, it's not a posture—it's a bug.

We also correlate vitals with route identity. A lot of perf problems are route-specific, not global.

If you don't attach route identity, you can't fix the right thing.

Counterpoint: teams sometimes over-fit to vitals and forget that "correct" and "understandable" are also UX.

I like making correctness evidence visible (freshnessAt, lane) alongside perf evidence. It keeps tradeoffs honest.

We used the [tips] log format to build a small "perf story" line per session.

It helped us review perf as a narrative instead of a spreadsheet.

Long-form counterpoint: if your UI model is unclear, perf work is wasted because you're optimizing the wrong thing.

Clarify lanes and identity first. Then measure. Otherwise you're just moving jank around.

If you implement a perf posture, start with evidence keys before you start measuring.

If you can't see posture, you can't reason about performance decisions.