Your React or Vue product site already updates the URL when someone clicks from pricing to checkout. The address bar looks like a new page. Search Console and PageSpeed Insights still treat most of that journey as one long document load, so Largest Contentful Paint (LCP) for the first paint stays on the initial hard navigation while later route changes never get their own Core Web Vitals story. Clients feel those transitions. Field tooling often does not.
Chrome has been working toward a browser-standard definition of those client-side route changes, called soft navigations. In Chrome 151 the soft-navigation and interaction-contentful-paint performance entry types ship for sites without a special flag. Barry Pollard's Measuring soft navigations guide (updated July 2026) states the feature is available for all sites from Chrome 151. What follows is a practical prep and measurement checklist for agencies: what soft navigations are, how Interaction Contentful Paint (ICP) relates to LCP on route changes, how to prepare the app so heuristics fire, what you can observe today, and where Apogee Watcher's scheduled lab runs still stop short.
What soft navigations mean for SPA Core Web Vitals
Chrome's working definition of a soft navigation is short. The navigation starts from a user action. It results in a visible URL change. The interaction results in a visible paint. Sites that miss any of those three conditions may see false negatives (route changes users treat as navigations that never emit soft-navigation entries). Sites that meet them too loosely may see false positives. Feedback still belongs in the soft navigation specification repository, not in invented thresholds.
For Core Web Vitals reporting, the gap has always been architectural. Multi-page apps get a fresh navigation timing origin on each full document load. Single-page apps replace content with JavaScript, push history, and keep the same document. Classic LCP, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) still run, but they were designed around that document lifecycle. Soft navigations give Chromium a shared way to slice metrics per route-like transition, independent of which framework performed the update. For metric definitions before you argue about SPA timing, start with LCP, INP, and CLS explained and our INP guide.
Soft navigations do not replace hard navigations. Cold loads, deep links, and full reloads still use the usual navigation and LCP entries. Soft navigations sit beside that model for in-app route changes once Chrome detects them.
What Chrome 151 ships for soft navigation measurement
Chrome 151 adds soft-navigation and interaction-contentful-paint entry types to the Web Performance API timeline. The beta notes describe them as establishing new time origins for route transitions so Core Web Vitals can be measured for soft navigations. You can feature-detect with PerformanceObserver.supportedEntryTypes.includes('soft-navigation') or check for SoftNavigationEntry on window while support is rolling out.
When soft navigations are active, Chrome changes how some timings report. A soft-navigation entry emits after each detected soft navigation. It carries a navigationId, the new URL in name, and an interactionId for the initiating interaction. One or more interaction-contentful-paint entries emit after interactions that cause a contentful paint; each can include a largestContentfulPaint property usable as LCP for that soft navigation when you map entries carefully. Soft-navigation entries also expose paintTime and presentationTime as FCP for that navigation, and getLargestInteractionContentfulPaint() to retrieve the largest ICP entry for that navigation without buffering every paint yourself.
Hard-navigation LCP from largest-contentful-paint still finalises on interaction as before. Soft-navigation LCP comes from ICP entries whose interactionId matches the soft navigation, not from every later interaction on the same document. Timings remain relative to the original hard navigation start time, so you subtract the soft navigation startTime when you report LCP relative to the route change. Chrome's docs recommend reporting TTFB as 0 for soft navigations for now, similar to back/forward cache restores, which is what the web-vitals library does.
DevTools already shows soft navigation and LCP markers in the Performance panel trace view, marked with * to distinguish them from hard navigations. That path is useful for verifying detection on a staging SPA before your RUM pipeline is ready. Walk the money routes once in the trace view so you know whether Chrome sees the same transitions your users feel.
How to prepare your SPA so soft navigations can be detected
You cannot force Chrome to invent a soft navigation for a route change that never updates the URL or never paints. Preparation is about matching the heuristic, not about shipping a private score. If the address bar stays put or nothing paints after the click, no observer will invent a Core Web Vitals slice for that journey.
Keep URL updates visible and history-friendly
Soft navigations require a visible URL change tied to the user action. Use the History API or Navigation API in ways users already understand: push or replace state when the primary content area represents a new destination, keep the back button coherent, and avoid silent content swaps that leave the address bar on the previous path. If marketing and product disagree on whether a filter panel is a "page," decide deliberately. Heuristics will not resolve product ambiguity for you.
Paint after the interaction that starts the transition
The third criterion is a visible paint after the interaction. If your router changes the URL before any paint, or paints before the URL update, Chrome still tries to reconcile ICP and soft-navigation ordering, but delayed paints and deferred URL updates create harder mapping. Prefer a clear sequence: user activates a control, content updates enough to paint, URL reflects the destination. Skeleton screens that paint count; invisible DOM mutations that never reach the screen do not.
Test detection before you promise clients soft-nav field data
Enable soft navigation heuristics in a local Chrome build if you need to verify early (chrome://flags/#soft-navigation-heuristics or SoftNavigationHeuristics features), then re-check on Chrome 151+ where the feature is intended to be on by default. Walk primary SPA flows in DevTools Performance, confirm soft-navigation markers appear on the money routes, and note false positives on overlays that change the hash without a real destination change. Feature-detect before you attach observers in production so older Chromium builds and non-Chromium browsers stay quiet.
How to measure soft navigations and Interaction Contentful Paint
Observe soft-navigation with a PerformanceObserver, including buffered: true if you need earlier entries on the page. On each soft navigation, finalise metrics for the previous URL, then start fresh for the new URL using name and navigationId. Map ICP entries to soft navigations with interactionId, and use getLargestInteractionContentfulPaint() so paints that happened before the soft-navigation entry was emitted still attach correctly.
Reset long-lived metrics the way Chrome's guide describes. When a new soft navigation starts, treat LCP, INP, and CLS as new series for that URL slice. Do not keep the previous route's largest paint or shift score as if the user never left. Subtract soft-navigation startTime from soft-nav LCP timings so reports are relative to the route interaction, not the original document load.
Expect incomplete coverage. Soft-navigation APIs are Chromium-first. Other browsers and older Chrome versions may report classic Core Web Vitals without soft-navigation slices. Many RUM vendors are still aligning to the shipped API shape after origin-trial changes. Plan dual reporting for a while: hard-navigation metrics for cross-browser history, soft-navigation slices where Chromium support exists. That dual view is the same spirit as keeping lab and field clocks separate in synthetic versus real user monitoring.
Content that stays on screen across routes also matters. Soft-nav LCP from ICP only considers new paints tied to the initiating interaction. A persistent banner that was already the hard-nav LCP may not be the soft-nav LCP when only the body text changes. Deep links into the same URL as a hard load can report a different LCP element than an in-app soft navigation to that URL. Document that difference for clients so they do not treat soft-nav LCP as a drop-in twin of cold-load LCP.
Soft navigations versus scheduled PageSpeed Insights monitoring
Scheduled PageSpeed Insights and Lighthouse runs still measure full document loads of the URLs you list. They do not walk your SPA click path and emit soft-navigation entries for every in-app route. That limit is honest product scope, not a bug in Chrome 151. If checkout is only reachable after three client-side transitions from the marketing homepage, a lab run of the checkout deep link still helps. It remains a hard navigation to that URL, not a soft navigation from pricing.
Agencies need both layers. Lab schedules catch regressions on public URLs after deploys: third-party tags, template changes, CDN mistakes. Soft-navigation instrumentation (RUM or first-party PerformanceObserver pipelines) catches whether route transitions themselves stay within agreed LCP and INP bands for Chromium users. Confusing the two produces the same failure mode as treating a single PageSpeed Insights paste as Search Console status. We unpacked when spot checks stop scaling in PageSpeed Insights versus automated monitoring. For SaaS product surfaces that live almost entirely behind soft navigations, pair this with the URL priorities in performance monitoring for SaaS.
Apogee Watcher stays on the scheduled lab and portfolio side: multi-tenant site lists, mobile and desktop strategies, budgets, and alerts when a listed URL regresses. Soft-navigation and ICP observation belong in your RUM or custom instrumentation until field tooling and CrUX-style aggregation catch up to the new entries. Layer Watcher for deploy confidence across many hostnames. Layer soft-nav measurement for SPA route truth on the products that need it. Do not claim Watcher already scores soft navigations as a first-class metric.
Related navigation performance topics will show up later on our calendar, including back/forward cache restores and Speculation Rules prefetch or prerender. Soft navigations solve a different problem. They measure in-document route changes once those changes look like navigations to users and to Chrome.
What to tell clients after Chrome 151 soft navigations ship
Keep the retainer script short. Account managers need one shared wording so engineering and SEO are not arguing past each other in the same thread. Put the bullets below in the monthly review deck, not only in a Slack reply after a client escalates.
- Soft navigations are Chrome's way to measure SPA-style route changes that update the URL and paint after a user action.
- Chrome 151 exposes
soft-navigationandinteraction-contentful-paintso teams can report Core Web Vitals per soft navigation in Chromium, with careful URL and interactionId mapping. - Lab PageSpeed Insights schedules still verify listed URLs as full loads. Soft-nav quality needs RUM or custom observers on the SPA itself.
- Field reports will lag while RUM vendors and aggregation pipelines adopt the shipped API. Do not promise overnight Search Console parity for soft-nav LCP.
- Done means hard-nav lab budgets stay green on public URLs, and soft-nav instrumentation (where you invested) shows stable route LCP and INP for the journeys you named.
Avoid inventing a soft-nav "Good" threshold Chrome has not published as a Core Web Vitals programme change. Use the same discipline you already use for LCP and INP definitions. Label soft-nav slices as Chromium-route metrics until standards and tooling settle, and keep hard-navigation budgets as the client-facing language you already report.
FAQ
What are soft navigations in Chrome 151?
Soft navigations are client-side route changes that start from a user action, change the visible URL, and produce a visible paint. Chrome 151 ships soft-navigation and interaction-contentful-paint performance entries so those transitions can carry their own timing origin for Core Web Vitals-style measurement in Chromium. Older Chrome versions and other browsers may still report only classic document-level metrics.
Is Interaction Contentful Paint the same as LCP?
Not exactly. Interaction Contentful Paint entries describe contentful paints after interactions. For soft navigations, LCP for the route is taken from the largest matching ICP entry (via largestContentfulPaint / getLargestInteractionContentfulPaint()), mapped with interactionId, with times adjusted by the soft navigation startTime. Hard-navigation LCP still uses largest-contentful-paint for the initial load.
Do soft navigations change how PageSpeed Insights scores my SPA homepage?
A standard PageSpeed Insights or Lighthouse navigation still loads the URL you request as a document. Soft-navigation APIs affect what you can observe in the page after Chromium detects in-app transitions. They do not turn a single lab run into a full click-path audit of every SPA route.
Should we wait for CrUX before instrumenting soft navigations?
No. Instrument and verify detection in Chromium now if SPA routes are commercially important. Field aggregation and cross-browser coverage will take longer. Keep scheduled lab monitoring on the public URLs you already sell, and treat soft-nav metrics as an additional Chromium slice until your RUM vendor documents support.
Does Apogee Watcher measure soft navigations today?
Watcher schedules PageSpeed Insights-backed tests on listed URLs and stores history, budgets, and alerts for those loads. Soft-navigation and ICP observation require page-side or RUM instrumentation. Use Watcher for portfolio deploy monitoring; add soft-nav measurement where SPA route quality is the product risk.
Pick one SPA money path (pricing to checkout, search to product, dashboard to settings). On Chrome 151 or a flagged build, record a Performance panel trace while you click through, confirm soft-navigation markers fire, then attach a PerformanceObserver for soft-navigation and interaction-contentful-paint on staging. Write down which URLs get soft-nav LCP and which never meet the three heuristics. Put the public deep-link URLs for those destinations on a Watcher or PageSpeed schedule so hard-navigation regressions still alert after the next theme or tag change. Soft navigations close a measurement gap Chrome owns. Scheduled monitoring still closes the portfolio gap agencies own.
Top comments (0)