CrUX Now Reports Soft Navigation Core Web Vitals: What Changes for SPA Field Data

For years, a single-page app has had an awkward relationship with Core Web Vitals. A user lands on your site, clicks through twelve routes, and Chrome's field data records exactly one page load. Everything after that first paint, every route change, every interaction, every layout shift, gets folded into that initial entry.

That is changing. With the September 2026 release, published October 13, the Chrome UX Report (CrUX) release notes list experimental Core Web Vitals variants for LCP, INP, and CLS that include soft navigations. If you ship a React, Vue, Svelte, or Angular app with client-side routing, this is worth an afternoon of your attention.

What a soft navigation is

Chrome's soft navigation documentation defines it with three criteria: the navigation is initiated by a user action, it results in a visible URL change, and the interaction results in a visible paint. A click on a client-routed link that updates the address bar and renders new content qualifies. A scroll handler that rewrites the URL does not.

The Soft Navigations API launched in Chrome 151 (and Edge 151). Firefox and Safari do not support it, so everything below describes Chromium-user data.

What CrUX added

According to the web.dev announcement, three new experimental metrics are available through the CrUX BigQuery dataset, the CrUX API, and the CrUX History API, and CrUX Vis shows them for any URL or origin:

• experimental_largest_contentful_paint_with_softnavs measures LCP across both hard and soft navigations.
• experimental_interaction_to_next_paint_with_softnavs segments INP by individual navigation, instead of attributing the whole session's interactions to the first page load.
• experimental_cumulative_layout_shift_with_softnavs evaluates layout shifts per view and URL.

In the CrUX API, soft-navigation metrics are reported under the URL the user navigated to, subject to the usual eligibility rules. The stable Core Web Vitals scores are unchanged for now; the experimental values sit alongside them.

How much it matters

The numbers in the announcement show who is affected. About 70% of CrUX origins have little or no soft-navigation traffic (under 5% of page views), so most sites will see nothing. But roughly 7 to 11% of origins use soft navigations for over half their page views, and among the top 1,000 sites that share is 35% on Android and 42% on desktop.

For those SPA-heavy origins, the shift is large. Among origins with 75 to 100% soft navigations on Android, the share with a "Good" LCP rose from 26% to 87%. Android INP pass rates roughly doubled for mostly-soft-navigation sites, though SPA-heavy sites still trail multi-page sites. CLS is expected to align with multi-page sites on desktop and nearly match them on Android.

The aggregate CrUX picture is a useful sanity check. The September 2026 release reports 55.9% of origins passing all three Core Web Vitals; with soft navigations included, that figure is 59.5%.

The direction makes sense. Previously, a fast first load followed by slow route changes looked identical to a fast first load followed by fast ones. And a slow initial load that was followed by many snappy transitions was never credited for them. The new metrics measure what users actually experience across a visit.

Why this is not just good news

It would be easy to read the LCP jump as a free win. Three cautions apply.

First, the metrics are labeled experimental, and Chrome says to expect month-to-month shifts as measurement improves. The team's stated plan is to graduate them in May 2027, subject to feedback, at which point Search Console will switch to the new data. Treat today's numbers as a preview, not a scoreboard.

Second, per-route measurement exposes problems that were previously averaged away. If one heavy route runs a long task on every transition, it now shows up under its own URL. The web.dev guidance is to reduce heavy main-thread JavaScript during route transitions, because that can still cause INP issues.

Third, the definition can produce false positives and false negatives on some sites, per Chrome's docs. If your router does something unusual, verify that your transitions are actually being counted.

Measure it in your own RUM

CrUX gives you the Chrome-wide view, but you will want per-route numbers from your own users. Feature-detect and observe soft navigations:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log(entry.name, entry.navigationId);
    }
  });
  observer.observe({ type: 'soft-navigation', buffered: true });
}

Each soft-navigation entry carries the new URL in name and a navigationId that distinguishes repeat visits to the same URL. That ID is also attached to paint, layout-shift, and event entries, so you can group them per navigation. The docs recommend an observer over getEntriesByType, which is limited to the first 50 buffered entries and is a poor fit for long-lived apps.

If you already use the web-vitals library, version 6.0.0 and later supports this directly:

import { onLCP, onINP, onCLS } from 'web-vitals';

const opts = { reportSoftNavs: true };
onLCP(sendToAnalytics, opts);
onINP(sendToAnalytics, opts);
onCLS(sendToAnalytics, opts);

Per the docs, TTFB is reported as 0 for soft navigations, and each entry includes a navigationURL, which you should store so you can slice results by route. Because Firefox and Safari lack the API, keep your existing reporting for them; the Navigation API can detect URL changes there, though it will not give you FCP or LCP.

What to do this week

• Check whether you are affected. If you use client-side routing, open CrUX Vis for your origin and compare the experimental metrics to the stable ones. If you are a multi-page site, expect no change.
• Look for route-level outliers. Per-URL soft-navigation data is where the surprises will be. Start with your most-visited transitions.
• Add reportSoftNavs to your RUM so you have your own per-route baseline before the metrics graduate.
• Audit route-change JavaScript. Long tasks during transitions are the most likely source of a bad soft-navigation INP.
• Plan for November. The web.dev post says the next CrUX release is expected to add experimental soft-navigation metrics for navigation types and FCP.
• Send feedback. Chrome is collecting it via the web-vitals-feedback Google Group and the WICG soft-navigations specification repository.

The underlying shift is simple: Core Web Vitals are moving from judging the first page load to judging the visit. For SPAs, that is a more honest measurement, and it rewards the teams who treated route transitions as performance work rather than an afterthought.