CrUX adds soft-navigation metrics: compare definitions before claiming a gain
Chrome’s experimental metrics include SPA route changes. Keep them separate from stable Core Web Vitals when reviewing performance.
Chrome has added experimental Core Web Vitals that include movement between views in a single-page application. The October 13 release gives teams a second measurement series to inspect alongside the stable one. It does not mean a site became faster on that date.
A soft navigation changes the visible content and URL without loading a new HTML document. That distinction matters when a visitor arrives on a product page, opens a category, and returns to a comparison view within the same application. A report tied to the initial load can describe that journey differently from a report divided by view.
The experiment has its own metric names
The CrUX release notes date the release to October 13 and identify September 2026 as the monthly collection period. The new fields are available through BigQuery and CrUX APIs. Preserve both dates when comparing an export with a deployment log.
| Dimension | Experimental field | Interpretation |
|---|---|---|
| Loading | experimental_largest_contentful_paint_with_softnavs | LCP includes full loads and eligible soft navigations. |
| Responsiveness | experimental_interaction_to_next_paint_with_softnavs | INP is evaluated across individual navigations. |
| Visual stability | experimental_cumulative_layout_shift_with_softnavs | CLS is divided across the measured views. |
Google explains the definitions in its CrUX metric reference. The Chrome team also states that stable Core Web Vitals remain unchanged while the experimental series is evaluated. A future transition is a separate event; the experimental field names alone do not establish a new Search ranking rule.
Compare two definitions before diagnosing a release
Consider an illustrative dashboard review: the stable series stays level while the experimental series looks better. No code changed in the observation window. The first question is whether the measurement divides a single browsing session into multiple units. Sending that difference straight to an engineering success report would skip the explanation that needs to be checked.
- Select one URL or origin and keep that scope fixed. Record the form factor and collection period.
- Request the ordinary and experimental fields for the same scope. Save the returned period and any missing fields.
- Check whether the site actually changes routes without a full document load. Match a representative journey to the implementation.
- Use a performance trace to inspect a slow transition, then choose a code change only when the trace identifies work worth fixing.
A missing eligible record is an evidence gap. Record it as unavailable rather than zero, and avoid comparing an origin-wide field result with a single route measured in the lab. The existing CrUX publisher benchmark explains another case where field availability and metric scope change what a comparison can support.
Keep the release decision tied to the same series
Maintain the stable series for ongoing comparisons and label the experimental view explicitly. If a team adopts the new fields for diagnosis, document the metric definition next to its observation window so an apparent improvement cannot silently cross a definition change.
This is a source-led explanation and proposed comparison procedure. SearchEngineAnswer has not queried a site panel for this article or measured a performance improvement. For changes that may affect traffic, use the technical SEO launch checks alongside performance evidence; neither substitutes for the other.
Keep learning
Ask a question or join the discussion