SPA Core Web Vitals in Chrome 151: Measure route transitions as experiences

Traditional page-load vitals answer important questions about the initial document: when its main content became visible, whether layout shifted, and how responsive the page was to interaction. In an SPA, later navigation may be handled through history changes and DOM replacement without a new document navigation. A session-level metric can therefore mix several routes into the first page’s lifecycle, while a conventional page-view event may say a new page occurred. The data sets use different boundaries even when the interface looks page-like to the user.

Do not begin by renaming an existing route-duration timer “route LCP.” First inventory the questions: How long until the new route’s primary content is visible? Did old or new content shift during transition? Was the interaction that initiated navigation responsive? Did the user encounter a loading, empty, or error state? Did the route eventually produce a form start, call click, booking, or accepted lead? Some of those can use standardized performance entries; others remain application events or business records.

Chrome’s current soft-navigation heuristic identifies page-like transitions using three elements: a user action, a visible URL change, and a visible paint. The browser work introduces a soft-navigation performance entry and identifiers that associate performance evidence with a transition. Documentation also describes interaction-contentful-paint and the ability to calculate metrics such as LCP, CLS, INP, and FCP for soft navigations under the supported model. The browser, rather than each framework, is attempting to identify the lifecycle boundary.

The rollout has moved through experiments and origin trials. Chrome published a final origin-trial announcement in April 2026 for Chrome 147 through 149, and documentation updated July 8, 2026 says the feature is planned to launch unflagged in Chrome 151. The stable web-vitals package does not yet make that equivalent to ordinary production support; Chrome points to an experimental soft-navs branch. Version timing and behavior can shift, so detect capabilities rather than infer them from a user-agent string, and pin the exact observer or library revision.

A route record should have an application navigation ID even when the browser feature is unavailable or the transition is not user driven. Generate it for every router candidate, then retain document_instance_id, prior route, target pattern, navigation_type, trigger, router and document timing origins, instrumentation version, feature-support state, and disposition. If the browser emits a navigationId, store a correlation result rather than replacing the application key. This gives the team a stable join across application transitions, browser metrics, analytics, errors, and later actions.

Use route patterns instead of raw URLs when parameters may contain identifiers or create excessive cardinality. Keep query dimensions only when they are governed and materially useful. Record whether the transition was user initiated, history traversal, redirect-like application logic, or programmatic state replacement. The soft-navigation heuristic is designed around user interaction; not every router change will qualify. Missing browser detection is a classification outcome, not a zero-millisecond route.

Maintain two related state machines. The application path is candidate → started → loading → committed, with terminal error, aborted, superseded, or restored branches. The browser path is unsupported or candidate → detected → accumulating → finalized, with terminal undetected or missing-with-reason branches. A record may finalize once; a superseded route cannot later become committed; and browser detection cannot exist without a document instance. Join by documented identifiers rather than whichever route is current when a callback runs. Most navigation-scoped entries use navigationId; interaction-contentful-paint maps with interactionId and getLargestInteractionContentfulPaint().

Define correlation statuses explicitly. Prefer an exact interaction and navigation-identity match; otherwise permit a documented temporal-only match inside bounded timing origins, mark multiple candidates ambiguous, and leave unmatched evidence unmatched. Never attach a late callback to the current route merely because it is the only route in memory.

Use a current, tested web-vitals integration where it supports soft navigations, or implement directly against documented browser entries with the same rigor. Do not fork the metric formulas casually. CLS requires grouping layout shifts within the correct lifecycle, LCP candidates can change as content renders, and INP attribution needs interaction entries rather than a router duration. A custom “route ready” metric can coexist, but give it a distinct name and definition.

Create test routes that exercise the boundary: cached content, delayed primary paint, a shifting skeleton, blocked interaction, route error, browser back and forward, a superseded click, and a programmatic URL update without interaction. Test bfcache restoration as a separate document-lifecycle fixture rather than calling it an SPA history transition. Capture traces, observer output, router logs, and telemetry for the same app and browser identities. State which transitions qualify and which remain unsupported or unclassified.

A dashboard showing reasonable percentiles is weak validation. It can hide duplicate sends, current-route race conditions, lost final routes, unsupported browsers recorded as fast, and metrics attached to the wrong URL. Compare the telemetry to trace evidence and DOM behavior on a small deterministic set. Then use production distributions to find cases the fixtures missed. Lab tests validate implementation; field data describes supported real-user conditions. Neither substitutes for the other.

A route-performance percentile needs an application-defined denominator independent of browser detection. Report all router candidates, candidates in browsers with the required feature, candidates the heuristic detected as soft navigations, transitions with each finalized metric, and sampled records. This makes heuristic precision and recall proxies reviewable: manually labeled fixtures can estimate false positives and false negatives, while production detection rate shows coverage rather than truth.

Segment by normalized route family, transition pair, device class, connection context where responsibly available, browser capability, release, and final disposition. Compare distributions and tails rather than one average. Do not apply Google's “good,” “needs improvement,” or “poor” labels to experimental route distributions unless Google publishes that exact route-level assessment contract. Annotate deployment and instrumentation changes so discontinuities are not mistaken for experience changes.

Join route evidence to analytics and lead systems through governed pseudonymous keys and time boundaries on the server. Do not place raw lead IDs, CRM status, email, phone, or other direct identifiers in browser telemetry. Define an exposure model: one qualifying route, a governed action window, one action denominator, and explicit multi-route handling. Compare action rates across route-performance bands while controlling for route family, device, traffic source, release, and support cohort, and treat the result as observational.

The first commercial use is usually release protection. Define route fixtures and field guardrails for the transitions that carry revenue: service list to service detail, location finder to location, estimator to form, account sign-in to workflow, or article to inquiry. Alert on instrumentation loss, error dispositions, and sustained distribution changes within comparable cohorts. Pair the alert with a release identifier and traceable example navigation so the engineering team receives evidence it can act on.