Core Web Vitals for SPAs: what Chrome 151 soft navigation metrics change

What is a soft navigation?

A soft navigation happens when JavaScript changes the visible page and URL without loading a new HTML document. React, Next.js and other client-side applications often use this pattern for in-app routes. To a visitor, the experience looks like a new page. Traditional performance tools have usually treated it as part of the original page session.

Chrome's definition requires a user action, a visible URL change and a visible paint. Chrome 151 adds the performance APIs needed to identify that transition and connect its timing entries to the correct route. This matters because a quick homepage load does not reveal whether a service page, filter, dashboard view or contact step becomes slow after the first click.

What the experimental CrUX metrics measure

The October 2026 CrUX release adds experimental versions of the three Core Web Vitals. They blend hard and soft navigations, while the existing stable metrics continue to work as before. The experimental label matters: Chrome is gathering feedback, values may change as the model evolves and the data should not be presented as a new ranking score.

CrUX exposes the new metrics through BigQuery, the CrUX API and the CrUX History API. CrUX Vis also provides a quick comparison for eligible URLs and origins. Page-level data still depends on the usual CrUX eligibility and data-volume requirements, so the absence of a route report does not prove that the route has no performance issue.

Which websites need to act now?

Prioritize this work when the site changes the URL and substantial page content through JavaScript, especially when visitors complete several steps without a full reload. Examples include client portals, dashboards, interactive catalogues and app-like marketing sites. A conventional multi-page website that requests a new document for each link is unlikely to see a material difference from these soft-navigation metrics.

Framework choice is not the diagnosis. Confirm what the browser actually does when a visitor follows a link. Some Next.js sites use client-side transitions extensively, while others behave closer to multi-page sites. The relevant question is whether the route transition creates a new view that deserves its own LCP, INP and CLS assessment.

A practical SPA performance audit workflow

Start with one business journey instead of testing random URLs. A service business might test landing page to service page to case study to enquiry form. An ecommerce team might test category to product to basket. Record both the first load and every route transition so a good landing-page score cannot hide later friction.

Use Chrome DevTools performance tooling to inspect soft-navigation markers and the work that follows each click. For production monitoring, the web-vitals library supports soft-navigation reporting in version 6.0.0. Keep the traditional measurements in parallel because older Chrome versions and other browser engines do not yet provide the same API support.

• Choose one high-value journey and list every URL-changing interaction in order.
• Compare stable CrUX data with the experimental soft-navigation metrics for the same origin or eligible route.
• Test on a representative mobile device and network, then repeat with a warm application session.
• Investigate route-level LCP content, long JavaScript tasks behind poor INP and late component movement behind CLS.
• Fix the largest verified delay, retest the same journey and preserve the before-and-after measurement context.

How to read a better score without fooling yourself

SPA-heavy sites may see experimental LCP, INP or CLS improve because the new model measures follow-up views separately instead of attaching a long session to the initial navigation. That does not mean every route became faster. It means the measurement boundary is closer to what the visitor experiences as an individual view.

Keep the stable and experimental series separate. Segment by route, navigation type, device and release period where the data allows it. Pair field measurements with a reproducible trace. A percentage change without the URL, sample window and implementation context is not enough evidence for a performance claim.

What changes for SEO and reporting?

Nothing changes in stable Core Web Vitals reporting today. Chrome says the experimental metrics are being evaluated with a target of graduating in May 2027, subject to feedback. Search Console is expected to switch only after graduation. Until then, treat the new values as early diagnostic evidence rather than a ranking update or a replacement for the stable report.

The useful change is operational: teams can identify performance problems deeper in an application before they become part of the stable reporting system. For SEO, UX and development teams, the shared goal is simple. Measure the routes real visitors use, repair verified friction and keep the page understandable and usable on every step of the journey.