How Do Soft Navigations Affect Core Web Vitals?

Soft navigations change what a Core Web Vitals observation represents. A visitor can move to another view inside a single-page application without loading a new HTML document. Measuring those transitions separately helps distinguish the first arrival from what happens later.

Chrome’s October 2026 CrUX release adds experimental versions of LCP, INP, and CLS that include these transitions alongside full page loads. The existing stable scores remain unchanged while the experiment is evaluated.

For an SEO or development team, the immediate task is to compare the two methods without mistaking a measurement change for a performance fix. Keep the entry-page experience visible, investigate slow transitions, and label the data source before reporting an improvement.

The status and product details below were checked on October 15, 2026.

What counts as a soft navigation?

A hard navigation loads another document. A soft navigation changes the current document’s content to present another view, usually through a client-side router.

Chrome’s soft navigation measurement guide defines detection around three conditions: a user action, a visible URL change, and a visible paint. The detector can still produce false positives or false negatives. A route change in your framework and a detected browser navigation are not automatically equivalent.

Check behavior, not the framework name

“Built with React” does not tell you whether a journey uses soft navigation. A site can render its first page on the server and still use client-side transitions afterward. Another site using JavaScript components may load a fresh document for each destination.

Consider a shop where the homepage loads from the server, category-to-product clicks stay within the app, and checkout opens a separately loaded page. One journey contains multiple navigation behaviors. Describing the entire website as either hard or soft loses useful context.

Start with a representative public journey rather than a technology label. Identify the entry URL, the links people follow, the destination URLs, and which transitions create a new document. If engineering confirms client-side transitions, check whether Chrome recognizes them.

This distinction is separate from whether the first response contains useful indexable content. If that is the underlying problem, the SSR versus CSR guide addresses rendering choices. A newly measured transition does not settle an indexing question.

How soft navigations change LCP, INP, and CLS

The three metrics continue to describe loading, responsiveness, and visual stability. The change concerns which views contribute observations and where their measurement boundaries fall.

Chrome documents the new identifiers in its CrUX metrics reference. The experimental variants combine hard and soft navigations; they are not a soft-navigation-only dataset.

LCP: measure the newly painted view

Largest Contentful Paint describes when the largest qualifying content is painted. Traditionally, an SPA’s initial document load supplied its LCP observation; a later route did not simply start another ordinary page-load LCP measurement.

A soft navigation supplies another loading opportunity. That can be fast when code and assets are already available, but it can still be slow if the destination waits on data or substantial work.

The important element may differ between a direct arrival and an internal transition. A persistent banner can dominate the initial load while newly painted product details matter during the transition. Compare the experience people actually take rather than assuming that identical destination URLs imply identical loading work.

INP: separate interactions by view

Interaction to Next Paint measures responsiveness across qualifying interactions. It is not the average click delay. Its calculation generally reflects the worst interaction while allowing outlier handling on pages with many interactions.

Segmenting an app visit into views changes the observation boundaries. An interaction encountered much later no longer has to characterize the entire earlier visit in the same way.

Boundary details still matter. Chrome notes that the interaction initiating a soft navigation usually belongs to the previous view. Do not assign every slow navigation click to the destination simply because that is where the visitor ended up.

CLS: reset the observation boundary

Cumulative Layout Shift uses the largest session window of qualifying layout shifts. The stable metric does not blindly sum every movement across an entire visit.

Soft-navigation boundaries divide the longer document lifecycle into individual views. That changes which shifts can contribute to each view’s result. It does not make an unexpected movement harmless, nor does it imply that every movement around a click counts in the same way.

For example, a product image that arrives without reserved space remains worth investigating when it displaces the controls a shopper is using. A different aggregate does not answer whether that experience is acceptable.

For the broader definitions and scoring context, see Core Web Vitals explained. Here the key question is which part of the journey each observation describes.

What changes in CrUX and Search Console today?

The September 2026 CrUX dataset release, published on October 13, introduced experimental soft-navigation variants. “September” describes the data release’s collection month; October is its publication date.

Chrome’s launch explanation says stable Core Web Vitals scores remain unchanged during evaluation. It aims to graduate the experiment in May 2027, subject to feedback, with Search Console switching afterward. That is a conditional target, not a fixed migration or ranking-update date.

Google’s Search Console documentation also describes groups of similar URLs and 28-day field observations. A group in that report is not necessarily the same scope as one URL queried elsewhere.

These distinctions explain why apparently conflicting charts can both be legitimate. An experimental origin-level mobile value and a stable desktop URL value are answering different questions.

The new measurements are worth reviewing now if your public site uses substantial client-side navigation. They do not justify marking an unresolved Search Console issue fixed.

Nor does a better experimental value guarantee a ranking increase. Google’s page experience guidance makes clear that good Core Web Vitals do not guarantee top positions. Keep relevance, actual user experience, and measurement methodology distinct when communicating the result.

Compare the two measurements on your site

Start with CrUX Vis, which was updated for the experimental release. Enter the public origin or URL you want to investigate and use the available soft-navigation comparison view.

Before interpreting the difference, preserve the scope:

1. Confirm the exact origin or URL. An origin aggregates more than one page.
2. Select the same device class for both measurements.
3. Record the displayed collection period.
4. Save the stable and experimental values for each metric.
5. Write down whether the site’s important journeys actually use soft navigations.

These controls prevent a change in reporting context from masquerading as a change in experience.

For repeatable analysis, the CrUX API, History API, and BigQuery dataset provide access to the experimental data. The metric names are:

• experimental_largest_contentful_paint_with_softnavs
• experimental_interaction_to_next_paint_with_softnavs
• experimental_cumulative_layout_shift_with_softnavs

The CrUX API documentation explains origin and URL requests, device form factors, percentiles, and collection periods. API access requires a configured key. No live API response or account-specific measurement is presented here.

A minimal comparison record can stay simple:

If URL data is unavailable, record that exact state. An origin result can be useful context, but it is not a substitute measurement of that page.

CrUX has eligibility and inclusion requirements; a missing record is not a zero value or an automatic failure. Likewise, your analytics pageview count does not establish that enough eligible CrUX experiences exist.

Read the experimental and stable results beside the journey map. A large difference on an app with frequent internal transitions is a reason to investigate population and lifecycle effects. A difference alone does not identify the script, image, or request to change.

Why a better percentile may not mean a faster page

A percentile can change when the observations included in the dataset change, even if the original observations stay exactly the same.

Consider this deliberately simplified example. It uses invented loading times and a nearest-rank percentile calculation for teaching. It is not real CrUX data, an implementation of CrUX’s internal processing, or a forecast for any website.

The sample begins with four hard-navigation LCP observations:

Now include twelve additional soft-navigation observations: 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 0.7, 0.8, 0.9, 1.0, 1.1, and 1.2 seconds.

For this illustration, the nearest-rank p75 is the value at position ceil(0.75 × n) after sorting the observations from smallest to largest.

With four observations, that is the third value: 3.4 seconds. With all sixteen observations, it is the twelfth value: 1.2 seconds.

None of the four original hard loads became faster. The second result contains more observations, many of which are faster transitions. Calling the change a 2.2-second optimization would misdescribe what happened.

There is another limit: the blended p75 is not the average of the hard-only p75 and the soft-only p75. Aggregating percentile summaries loses the underlying distribution. Do not average dashboard percentiles to rebuild a combined result.

The practical implication is straightforward. If your experimental number looks better, preserve the cold-entry question: how long does a new visitor wait before seeing useful content? Then ask a second question: how does the site behave when that visitor moves to another view?

Both experiences matter. A faster transition does not compensate for an unusable first visit, and a good first load does not prove that every later step is responsive.

Use the actual report values for decisions. The toy calculation only explains why a measurement improvement and an engineering improvement are different claims.

Diagnose missing data and conflicting reports

When numbers disagree, establish what each number describes before looking for a performance regression.

Chrome’s native Soft Navigations API is enabled from version 151. Older versions and other browsers can differ in support, so ask what your own real-user monitoring implementation actually collects.

A developer can use the following diagnostic example to observe supported navigation entries. It is not a complete Core Web Vitals collector and has not been run against your website.

if (PerformanceObserver.supportedEntryTypes.includes("soft-navigation")) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log(entry.name, entry.navigationId);
    }
  });

  observer.observe({ type: "soft-navigation", buffered: true });
}

This helps answer a narrow question: did the browser emit a recognized soft-navigation entry, and which URL did it associate with it? It does not by itself calculate LCP, INP, or CLS.

If the entry exists but the destination feels slow, examine the actual journey. Separate waiting for data, loading route code, rendering content, and handling the triggering interaction. Keep any proposed fix tied to evidence from that route rather than applying a generic optimization list.

If the issue is a difference between field data and an isolated test, PageSpeed Insights measurement guidance explains that separate problem. Repeating a local test until one run looks good does not resolve a population or methodology mismatch.

Decide what to fix and what to report

Keep the engineering question specific. “Our experimental score improved” describes a report. “The product transition waits for an unnecessary request before painting useful details” describes a possible fix, once supported by an actual trace.

A practical review should preserve three workstreams:

1. Entry experience. Keep checking important pages as direct arrivals, including destinations often reached from search.
2. Transition experience. Inspect the routes where visitors move between views and the interactions that initiate those moves.
3. Measurement consistency. Identify which dashboards and targets use stable, experimental, or independently collected observations.

You can record a methodology change without claiming a speed gain. An illustrative stakeholder note might read:

Experimental CrUX values now include recognized soft navigations. They differ from our stable baseline, so we are retaining both series. This comparison does not demonstrate a release-related speed improvement. The next investigation covers direct product-page arrivals and category-to-product transitions separately.

Attach the real URL or origin, device, collection dates, metric keys, and values when using that note in practice. Do not replace unavailable fields with invented estimates.

For ongoing checks, Screpy’s Core Web Vitals monitoring provides a separate lab view of selected page measurements. It should not be presented as the experimental CrUX transition dataset. Its TBT measurement is also not an INP result.

Before closing an investigation, verify that the documented problem improved under comparable conditions. A lighter route bundle might help a transition; a faster data response might address waiting; reserved image dimensions might prevent a visible displacement. Select the change because it addresses the observed cause, then repeat the relevant observation.

Retain the previous reporting method until a deliberate migration is justified. Record when the metric definition, population, or tool changes, just as you would record a deployment. That gives readers of the next report a way to distinguish a faster experience from a different way of measuring it.