Google’s CrUX Now Tracks Soft Navigations, and That Changes Who Gets Measured

Google has added experimental soft navigation metrics to the Chrome UX Report, the dataset behind Core Web Vitals field data. Search Console is expected to follow. The metrics are experimental, which means they are not yet part of the official Core Web Vitals scoring set, but they are now visible in CrUX.

What actually changed

CrUX has historically measured page loads. A user navigates to a URL, the browser fetches a document, and the performance of that load gets recorded. Soft navigations are different: they are in-app page changes that happen without a full document load, the kind produced by client-side routing in single-page applications and JavaScript-heavy frameworks. Until now, those transitions were largely invisible to field measurement.

According to searchenginejournal.com, the new metrics are experimental and count these in-app page changes. Search Console is set to follow, meaning the same data will eventually surface in the tool most site owners actually look at.

Why this matters more than a typical metrics update

The gap CrUX had was not a rounding error. It was a structural blind spot. If your site renders most of its content through client-side navigation, a large share of what your users actually experience was never captured in the field data that Google uses to evaluate page experience. You could have a fast initial load and a sluggish, janky experience on every subsequent click, and the numbers would look fine.

That asymmetry shaped behavior. Teams optimized the thing that was measured, because the thing that was measured was the thing that showed up in reports and in conversations with stakeholders. Soft navigations sat outside that loop. Adding them to CrUX does not immediately change any ranking signal, since these are experimental metrics, but it changes what is observable. And what is observable tends to become what is managed.

The practical read for different kinds of sites

If your site is a traditional multi-page setup where every click loads a new document, this news is close to irrelevant to you. Your navigations were already being counted. Nothing about your reporting changes in a meaningful way.

If you run a single-page app, a headless front end, or anything with heavy client-side routing, the picture is different. The transitions between views are now something Google can see in aggregate field data. That does not mean you will be penalized tomorrow. It means the measurement floor has moved, and the excuses for not instrumenting those transitions are getting thinner.

There is a real technical wrinkle here that site owners should not gloss over. Soft navigation measurement is harder than page load measurement. Deciding what counts as a navigation, when a view is “complete,” and how to attribute layout shift or interaction latency to a specific transition are genuinely unsettled problems. That is presumably part of why these metrics are labeled experimental rather than shipped as official vitals. Expect the definitions to shift, and expect early numbers to be noisy.

What to watch next

The obvious thing to track is the Search Console rollout. Once these metrics appear there, they stop being a curiosity for performance engineers and start being something that shows up in a report a marketing lead opens on a Monday morning. That is the moment the internal conversation changes.

The second thing to watch is whether these experimental metrics eventually get promoted into the Core Web Vitals set itself. Google has not said that, and treating it as inevitable would be reading too much into an experimental label. But the direction of travel is clear: the company keeps expanding what it measures toward what users actually experience, and soft navigations were the largest remaining hole in that picture.

For now, the sensible posture is to start paying attention to client-side transition performance even though nothing is forcing you to. If you have a single-page app and you have never measured what happens between route changes, you now have a reason that is external to your own team’s priorities. That is usually when things get fixed.