Soft navigation metrics are now available experimentally in the Chrome UX Report (CrUX), giving single-page applications a way to measure Core Web Vitals across in-app navigations rather than only the initial page load.
Google’s Chrome team published the change on 13 October 2026. For developers running React, Vue or other SPA-heavy sites, the important point is not that rankings changed overnight. The current stable Core Web Vitals remain in place, while the new data provides an early view of how SPA performance may be measured more accurately in future.
What soft navigation metrics change in CrUX
Traditional page loads fetch a new HTML document. Single-page applications often behave differently: JavaScript intercepts navigation, changes the URL and replaces page content without a full reload. To users, this can feel like moving to a new page, but historically many performance tools treated the session as one long document lifecycle.
That created a measurement gap. A fast initial load could be followed by slow in-app transitions, delayed interaction or layout shifts that were difficult to attribute to a specific route. Conversely, later problems could be rolled into the original page’s metrics rather than measured as separate navigations.
Chrome 151 introduced the Soft Navigations API, and the October CrUX release now exposes experimental versions of all three Core Web Vitals that include these navigations:
- Largest Contentful Paint (LCP) with soft navigations.
- Interaction to Next Paint (INP) with soft navigations.
- Cumulative Layout Shift (CLS) with soft navigations.
Where developers can see the new CrUX soft navigation data
The experimental metrics are available through the CrUX BigQuery dataset, the CrUX API and the CrUX History API. CrUX Vis has also been updated so site owners can compare the experimental values with existing stable measurements without building their own reporting pipeline first.
Google’s documentation lists the experimental fields separately from the stable Core Web Vitals. That separation matters: teams can investigate the new data without assuming it has already replaced the metrics used in current Search Console reporting.
For developers who want more detail than CrUX provides, Chrome also documents how to measure soft navigations in their own real-user monitoring setup. CrUX is aggregated field data, so custom RUM can still be useful when route-level diagnosis is required.
Why Core Web Vitals for SPAs needed this change
A conventional multi-page website naturally creates a new measurement lifecycle on each navigation. An SPA may keep the same document alive while users move through product pages, dashboards or account screens. That architectural difference should not mean the later user experience is invisible.
For example, a dashboard may load quickly on first visit but take several seconds to render a reports view after a client-side route change. Another route may introduce a large layout shift after fetching data. Measuring only the first load can understate the experience users actually have during a longer session.
This is particularly relevant for application-like websites where the most commercially important interactions happen after the landing page. Nevelit’s earlier Chrome 154 testing guide discussed why browser changes need to be tested against real application behaviour rather than treated as abstract release notes.
What changes in Search Console?
For now, nothing immediate changes in the stable Core Web Vitals report. Google says the soft-navigation variants are experimental and may change as the implementation receives feedback.
The Chrome team aims to graduate the metrics from experimental status in May 2027, subject to feedback. Once that happens, Google says Search Console is expected to switch to the new data.
That timeline gives SPA owners a useful testing window. It does not justify treating today’s experimental numbers as a new ranking score. Google Search Central continues to describe Core Web Vitals as part of a broader page-experience picture, not a standalone guarantee of rankings.
Search Console itself is also evolving in other areas. Nevelit’s Search Console multimodal reporting overview is a reminder that new reports often improve diagnosis before they change how teams should make decisions.
How small teams should use the experimental data
Compare stable and experimental results
Start by checking whether the new metrics materially change the picture for your origin or important URLs. A small difference may not deserve immediate engineering work. A large gap can indicate that later SPA navigations deserve closer investigation.
Test representative user journeys
Do not stop at a homepage score. Follow the routes customers actually use: search, product detail, checkout, account screens, dashboards or forms. If a soft navigation performs poorly, reproduce it under realistic conditions before changing code.
Use route-level RUM where needed
CrUX can reveal that a problem exists, but aggregated data may not identify the route or code path responsible. For complex applications, instrumenting LCP, INP and CLS around soft navigations can help connect field problems to specific transitions.
Prioritise user impact, not a perfect score
Google’s current guidance explicitly warns against optimising only for a perfect Core Web Vitals score. If an experimental metric changes but users are not experiencing a meaningful problem, investigate before committing engineering time.
Limitations and trade-offs
The new metrics are experimental. Google expects the implementation to evolve, so month-to-month changes may reflect measurement improvements as well as changes on the site itself.
Soft navigation detection also has to work across many SPA architectures and routing patterns. That complexity is one reason Chrome is collecting feedback before graduation. Teams should therefore keep notes about browser versions, deployment dates and measurement methods when comparing results.
There is also a reporting trade-off. Better route-level measurement can make some SPA performance look worse because previously hidden slow transitions become visible. That is not necessarily a regression. It may simply be a more complete description of what users were already experiencing.
Critical analysis
The value of this change is measurement accuracy, not a new SEO shortcut. SPAs have long been awkward to assess with page-load-centric metrics, and the experimental CrUX fields provide a more realistic view of how performance changes during a session.
The cautious rollout is sensible. Search Console has not switched yet, the fields are explicitly experimental, and Google has given a target rather than a guaranteed May 2027 transition. Developers therefore have time to validate their own applications before the data becomes part of normal reporting.
For businesses, the practical question is simple: do later navigations feel slow, unstable or unresponsive to real users? The new metrics can help answer that question. Treating them as an early diagnostic tool is more useful than chasing a score before the methodology is final.
Sources
- web.dev – Experimental soft navigation metrics now available in CrUX, 13 October 2026.
- Chrome for Developers – CrUX metrics documentation, updated 13 October 2026.
- Search Engine Journal – Google Adds Experimental Soft Navigation Metrics To CrUX, 13 October 2026.
- Google Search Central – Understanding Core Web Vitals and Google search results, checked 15 October 2026.
Leave a Reply