By the DenverSEO.io team · 2026-10-19
The Chrome UX Report’s September 2026 dataset (published October 13, 2026) adds experimental Core Web Vitals for soft navigations, the in-app route changes single-page applications make without a full page load. Measured with soft navigations included, 59.5% of origins pass Core Web Vitals versus 55.9% on page loads alone, and the LCP pass rate rises 5.6 points. Thresholds did not change. Sites built as SPAs are now being measured on the transitions users actually experience, which helps well-built apps and exposes slow ones.
What a soft navigation is
A traditional website loads a new document for every page. A single-page app (React, Vue, Angular, Next.js in client mode, and most “headless” storefronts) loads one document and then swaps content in place when you click. The URL changes, the view changes, but the browser never performed a navigation. Those in-place changes are soft navigations.
Until now, Core Web Vitals in the field only captured the first, hard load. A SPA with a slow initial bundle but instant transitions looked bad; a SPA with a fast shell and sluggish, layout-shifting route changes looked good. Neither reflected what a user felt for most of the visit.
What CrUX changed
The Chrome UX Report release notes for the September 2026 dataset describe experimental soft-navigation metrics: LCP, CLS and INP attributed to each in-app transition, with the heuristics Chrome uses to decide that a route change counts (a user interaction, a URL change, and a meaningful DOM update). The headline figures from the same release notes:
- 55.9% of 18.4 million origins have good Core Web Vitals measured on page loads alone.
- 59.5% pass when soft navigations are included.
- LCP pass rate improves by 5.6 points under the soft-navigation view, because in-app transitions usually paint faster than a cold load.
- Per-metric pass rates on loads: LCP 68.3%, CLS 81.7%, INP 85.4%.
- INP regressed across the web in the August 2026 dataset, which the notes flag separately.
Thresholds did not move. Good is still LCP at or under 2.5 seconds, CLS at or under 0.1, INP at or under 200 milliseconds, at the 75th percentile. Anyone telling you “LCP is now 2.0” is reading a blog, not the release notes.
Who this affects
SPA and headless sites. You now get credit for fast transitions, and blame for slow ones. A route change that fetches data, then renders a skeleton, then shifts layout when the data arrives, now shows up as a CLS and LCP event instead of being invisible.
Multi-page sites. Nothing changes. Hand-coded static sites like this one perform hard navigations, which were always measured. If your site is server-rendered HTML with no client router, this release is informational.
Sites in the middle. WordPress themes that use a JavaScript “page transition” plugin, Shopify themes with a client-side cart drawer and filtered collection pages: some of those interactions may now register as soft navigations. The INP regression noted for August is a reminder that these interactions were already being measured by INP; soft-navigation attribution just makes the cause easier to see.
How to check your own site
- CrUX Dashboard or the CrUX API. Look for the experimental soft-navigation fields in the September 2026 dataset onward. If your origin has enough traffic to be in the report, you will see page-load and soft-navigation views side by side.
- Chrome DevTools, Performance panel. Record a session, click through three routes, and look for the soft-navigation markers and the LCP/CLS entries attributed to each.
- Lab test every route, not just the home page. Run Lighthouse on the deep pages a user lands on from search, and on the page they reach after one click.
What usually fixes a slow soft navigation
- Reserve the layout. Skeletons that match the final layout dimensions, fixed heights for images and cards, no content injected above the fold after data arrives. This is the same CLS work as always; it now counts twice.
- Prefetch the next route’s data on hover or in idle time. The transition paints instantly because the data is already there.
- Break up long tasks. INP is where SPAs lose most often. A click handler that re-renders a large tree in one go is a 300-millisecond interaction. Yield to the main thread; our INP note has the pattern.
- Ship less JavaScript on the critical route. Code-split by route; defer analytics and chat until after the first interaction.
And the honest alternative: if the site does not need to be a SPA, do not make it one. A server-rendered page with a few lines of JavaScript performs a hard navigation in under a second on a phone, is measured correctly, and is readable by every crawler. Our SEO web development page explains how we decide.
Why an SEO site cares
Core Web Vitals remain a Google ranking consideration within the page experience signals, and more importantly they describe whether a visitor stays. The Web Almanac 2025 found only 48% of mobile sites passing all three metrics. The September 2026 CrUX release does not raise the bar; it measures more of the experience against the same bar. For a well-built app that is a gift. For a slow one it is a diagnosis.
