Soft Navigations and Core Web Vitals: What Chrome 151 Changes for SPA-Style Websites

For years, Core Web Vitals mostly described the first page load of a single-page app. Click from the homepage to Services to a case study, and the browser still treated it as one long visit to the first URL. Chrome 151 changes that. It can now detect soft navigations, the JavaScript route changes that React, Vue, Angular, and Next.js sites rely on, which makes it possible to attribute LCP, INP, and CLS to each route.

Short answer: Soft navigations Core Web Vitals measurement is live by default in Chrome 151 and reported through the open-source web-vitals library (v6+). It gives you per-route numbers for SPA-style sites. It does not yet change what CrUX or the Search Console Core Web Vitals report show. Treat it as a better diagnostic signal now, and design route changes like real page loads before Google decides how CrUX will use it.

Facts below are as of October 5, 2026, checked against Chrome for Developers, the GoogleChrome web-vitals repository, Google Search Console Help, and Next.js docs. If you need the basics first (the three metrics, field vs lab data, a DIY fix order), start with our Core Web Vitals for small business websites guide.

Soft navigation in plain English

A hard navigation is the classic web: you click a link, the browser requests a new HTML document, and the page loads from scratch.

A soft navigation happens inside an app that is already loaded. JavaScript swaps the content, updates the URL with the History API, and the Back button still works. To the visitor it feels like a new page. To the browser, historically, it was the same document.

Chrome's soft navigations documentation now defines one with three conditions:

1. The navigation is initiated by a user action.
2. It results in a visible URL change.
3. The interaction results in a visible paint.

Chrome is candid that the heuristic can produce false positives and false negatives. One practical consequence: a route change your code triggers on its own, with no click or tap, does not count.

The same page admits that the popular single-page application architecture "has never been fully supported by the Core Web Vitals metrics." That gap is what Chrome 151 is meant to close.

Why this matters now

Three dated changes landed this summer and fall:

• July 21, 2026: the GoogleChrome web-vitals library v6.0.0 "introduces Soft Navigation support." You opt in with a reportSoftNavs: true option. Patch releases have kept coming, with v6.2.3 published October 5, 2026.
• July 28, 2026: Chrome 151 reached stable with two new performance entry types, soft-navigation and interaction-contentful-paint. Per the release notes, a soft-navigation entry establishes "a new time origin to attribute subsequent performance data to the active route rather than the initial document URL."
• September 2, 2026: Chrome's soft navigations guide was updated to state the feature "is enabled by default from Chrome 151," with DevTools support in the Performance panel's Live Metrics and trace views.

So the measurement exists in shipped Chrome, the reference library supports it, and the debugging tools show it. What has not happened yet is the part most SEO teams care about: field data in Google's own reports.

What changes for each metric

Once Chrome detects a soft navigation, metrics restart for the new route. According to Chrome's guide and the web-vitals reporting table:

Two details surprise people.

First, the LCP element can change. Chrome's own example: a big banner image is the LCP element on the first load, but on later soft navigations only the text below it changes, so that text becomes LCP. Deep-link the same URL cold and the banner is eligible again. Same URL, different LCP element, depending on how the visitor arrived.

Second, a slow route change shows up as a slow LCP on the destination route. On an SPA, "the homepage scores fine" no longer covers the rest of the site.

What does not change yet: CrUX, Search Console, other browsers

This is where to keep expectations honest.

• CrUX: Chrome's guide says how soft navigations "will be reported in CrUX ... is also still to be determined," and that Chrome will announce CrUX changes later. DebugBear's August 27, 2026 update says the same in plainer terms: CrUX still reports Core Web Vitals for hard navigations only.
• Search Console: Google's Core Web Vitals report help states the report's data "comes from the CrUX report." Our reading: until CrUX changes, your Search Console report will not show per-route soft-navigation data.
• Rankings: Google Search Central still says good Core Web Vitals align with what its core ranking systems seek to reward. Nothing official ties soft-navigation metrics to Search today. Do not promise anyone a ranking change from this.
• Other browsers: this is Chromium only. Safari and Firefox visitors will not report soft-navigation metrics, so your per-route data will be a Chromium subset.

Our view: the near-term value is diagnostic. You can finally see which routes feel slow to real users. Long term, Chrome says the aim is to fold these measurements into Core Web Vitals "as exposed by all tools," which is a good reason to fix route changes before the scoreboard moves.

How to measure soft navigations without breaking your baseline

Because the new APIs are Chromium-only, Chrome's guide suggests sites may want to measure both ways for now: the traditional view (which lines up with CrUX) and the per-route soft-navigation view. With web-vitals v6, that means two sets of callbacks:

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

// Traditional view: lines up with CrUX
onLCP(sendTraditional);
onINP(sendTraditional);
onCLS(sendTraditional);

// Per-route view: Chromium 151+ soft navigations
onLCP(sendSoftNav, { reportSoftNavs: true });
onINP(sendSoftNav, { reportSoftNavs: true });
onCLS(sendSoftNav, { reportSoftNavs: true });

A few rules from the library and Chrome's guide:

• Report against navigationURL, not the current address bar. Metrics can arrive after the visitor has moved on.
• Store the navigation type so you can segment soft from hard loads. Chrome notes they may have different characteristics, so keep them in separate views.
• Ask your RUM vendor whether it supports soft navigations natively before you hand-roll anything.
• Expect two data streams to look different. That difference is the point, not a bug.

For quick checks, open Chrome DevTools, record a Performance trace, click through a few routes, and look for the soft-navigation markers.

Route-change checklist for design and build

Measurement shows you the problem. These are the design and build decisions that usually decide the number. Treat this as our working checklist, not a Google spec.

1. Name the largest new element on each route. If every route swaps a hero image, that image is probably the soft-nav LCP. Size it, prioritize it, and do not lazy-load it.
2. Show something useful fast. In Next.js, a loading.tsx fallback gives immediate visual feedback during dynamic routes, and useLinkStatus can show a pending hint on slow networks (per Next.js docs).
3. Reserve space for route content. Skeletons that match final layout height reduce shifts when data lands.
4. Keep sticky headers and banners stable. Persistent UI that resizes or reflows on every route change is a classic CLS source.
5. Keep click handlers light. The interaction that starts a route change counts toward INP on the page you leave. Heavy analytics or state work on click hurts it.
6. Prefetch deliberately. Next.js prefetches <Link> routes in the viewport. That helps speed. Disabling it everywhere can slow dynamic routes.
7. Test a deep link and an in-app click for the same URL. They can produce different LCP elements. Both experiences matter.
8. Check on a mid-range phone, not only a fast laptop.

Next.js note: its docs say <Link> performs client-side transitions that update content "instead of reloading the page." Our reading is that those transitions will often count as soft navigations under Chrome's definition when a visitor clicks, the URL changes, and new content paints. Verify on your own site in DevTools.

When to bring in a development partner

Plenty of teams can add two callbacks and read a dashboard. The harder part is acting on what the data says: restructuring data fetching, splitting bundles, rethinking transitions, and keeping a design system consistent while you do it.

• DIY-strong: you have a developer, a RUM tool, and clear ownership of the front end.
• Hybrid: you have the data but need someone to turn slow routes into a prioritized fix list.
• Partner-led: the site was built on a framework nobody in-house really owns, or every redesign quietly makes route changes slower.

If you are weighing whether a custom React or Next.js build is even the right fit, our custom React and Next.js web development guide covers that call. When you want a team to own front-end performance alongside the build, start at web development.

FAQ

Are soft navigations a new ranking factor?

Nothing official says so. Google's Search Console Core Web Vitals report uses CrUX data, and Chrome says how CrUX will report soft navigations is still to be determined.

Do I need Chrome 151 to see the data?

Yes. Soft-navigation entries are emitted by Chromium 151 and later. Other browsers will not report them, even with reportSoftNavs turned on.

Is my site an SPA if it uses Next.js?

Next.js server-renders pages and then uses client-side transitions for <Link> clicks. Our reading: those in-app transitions will often register as soft navigations in Chrome 151+, even though the first load is a normal page load. Confirm in DevTools.

Should I stop tracking traditional Core Web Vitals?

No. Keep the traditional view because it lines up with CrUX and Search Console. Add the soft-navigation view alongside it.

Conclusion

Soft navigations Core Web Vitals measurement finally lets SPA-style sites see per-route LCP, INP, and CLS in Chrome 151 and web-vitals v6. CrUX and Search Console have not changed yet, so treat it as a sharper diagnostic tool, not a new score to chase. Measure both views, name the largest new element on each route, keep transitions stable, and test deep links as well as clicks. When route-change performance needs a real owner, contact us.