CrUX Adds Experimental Core Web Vitals for SPA Navigations

CrUX now has experimental LCP, INP, and CLS metrics that account for navigation within single-page applications. Site owners can compare them with the stable metrics in CrUX Vis.

· 5 min read · 5 comments

Chrome has added experimental versions of all three Core Web Vitals to the Chrome User Experience Report (CrUX), accounting for navigation within single-page applications without a full page reload. As Search Engine Journal reports, the data is available in BigQuery, the CrUX API, and the History API starting with the October 13 CrUX release. If your site uses this kind of navigation, you can already compare the stable and experimental metrics in CrUX Vis. The stable scores have not changed.

How CrUX Accounts for Navigation Within an App

Previously, CrUX measured the initial load of a single-page application. Subsequent interactions and layout shifts were attributed to the entry page, even after someone had moved to different content. That made it difficult to see how individual app routes performed: their metrics did not appear in the data for the corresponding URLs.

The experimental versions of LCP, INP, and CLS now cover both full page loads and detected “soft navigations.” Chrome identifies a soft navigation when a user action changes the visible URL and updated content appears on screen. The metrics for that view are attributed to the destination URL, provided the usual conditions for inclusion in CrUX are met.

Soft navigations are detected using the Soft Navigations API. It has been enabled by default since Chrome 151, released on July 28. The new metrics sit alongside the stable ones rather than replacing them: CrUX Vis now has an Include soft navigations toggle for comparing the two.

Where the Scores May Differ Significantly

For most sites, the difference is likely to be small. Depending on the platform, 66–75% of origins in CrUX—the units used to group views in the report—have a soft-navigation share below 5%. Soft navigations account for more than half of views for 7.0% of origins on Android and 10.6% on desktop. Among the top 1,000 sites, those shares are higher: 35% on Android and 42% on desktop.

When most views come from navigation without a reload, the experimental scores improve for all three metrics. Among Android origins where soft navigations account for 75% to 100% of views, 26% receive a good LCP rating under the stable metric, versus 87% under the experimental one. That does not mean single-page applications are generally faster than sites that load each page afresh. As Chrome explains, subsequent navigations are usually faster than the initial load, regardless of how a site is built.

For INP, the distribution of interactions changes: responsiveness is assessed within each view rather than by the slowest interaction across the entire session. Among Android origins that predominantly use soft navigations, the share passing the INP threshold roughly doubles. They still lag behind sites with full page loads, though: heavy JavaScript work when content changes can affect responsiveness.

Layout shifts in the experimental CLS are also distributed across views instead of being accumulated over the entire session. On desktop, this puts sites with a high share of soft navigations roughly on par with multipage sites; on Android, a small gap remains. In the September dataset, 55.9% of origins had good Core Web Vitals without accounting for soft navigations, compared with 59.5% when they were included.

What Site Owners and Teams Should Do

If your site changes its content and URL without a full page reload, it is worth having your developers turn on the toggle in CrUX Vis. The comparison will show how much the scores differ and which metric changes most when internal navigations are treated as separate views. If every navigation involves a full page load, you should not expect a noticeable difference.

I would advise site owners and marketers not to take better experimental scores as evidence that the interface has become faster. The site has not changed; what has changed is how measurements are attributed to views and URLs. When discussing the results with your team, it is worth clarifying exactly which metrics you are comparing, especially for a single-page service.

For now, these metrics remain experimental, and Chrome warns that results may change from month to month as the measurements are refined. The November CrUX release is expected to include FCP and navigation-type metrics that account for soft navigations. Chrome expects to conclude the experimental phase in May 2027, but the timing depends on feedback. Once the metrics leave experimental status, Search Console is expected to start using the new data; the article does not specify what status they will have next.

My Take: It’s Not Just the First Screen That Matters

I like that measurement is getting closer to the way people actually use a single-page interface: they do not stop after the initial load. Especially in a complex service, I want to see not only how quickly someone gets in, but also what happens after they choose a section or take the next step.

At the same time, I would not present a higher share of good LCP scores to a team as proof that the problem is solved. A navigation might help someone move forward—or leave them waiting for the next action. The experimental data helps frame the question more precisely. I would look for the answer in a specific user journey, starting with how it feels on a mobile screen.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

  1. Google Adds Experimental Soft Navigation Metrics To CrUX via @sejournal, @MattGSouthern www.searchenginejournal.com

About the author

Pavel Voronov

UX/UI designer for digital products

I design interfaces and help teams agree on what users really need. I like evaluating speed not only through Lighthouse, but also through how it feels to a person.

All posts by the author

Discussion 5

Leave a comment

Not published. We’ll send a link to confirm your comment.

No links or ads. Your first comment is published after review. By sending a comment you agree to the privacy notice.

  1. Roman Ostapenko

    One practical caveat: route-level CrUX data is only useful if the app’s navigation and URL state stay aligned. If content changes without a meaningful URL update, the new metrics may still be hard to interpret by route.

    1. Gerrit Oosten

      @roman.ostapenko CrUX route attribution also depends on consistent URL canonicalization, so query parameters or trailing-slash variants can split what teams consider the same route.

      1. Tomas K.

        Another wrinkle is that SPA transitions can update the URL before the destination content is ready, so consistent canonicalization alone won’t guarantee the route’s metrics reflect the right experience. I’d verify the app’s URL changes and transition timing alongside the experimental data before comparing routes.

      2. Marta Hurtado

        @gerrit.oost Good point—would CrUX normalize trailing slashes for these experimental route metrics, or should teams check the raw URL variants in CrUX Vis before comparing them? I’m curious how much canonicalization is handled automatically vs left to the site.

    2. Oliver Lopes

      @roman.ostapenko I’ve run into this with apps where a tab swaps the main content but leaves the URL untouched: CrUX can tell you the experience changed, but not which route to blame. Updating history state only when the content genuinely represents a new destination makes the experimental route data much easier to act on—and saves everyone from debugging a dashboard full of misleading attribution.