Could Better SEO Make Core Web Vitals Look Worse?

Google Has Fixed an SPA Measurement Gap — But Raised a New Question

On 13 October 2026, Google announced experimental Core Web Vitals measurements that include soft navigations. For Single Page Applications (SPAs), this addresses a longstanding gap: a fast transition between internal views could not previously contribute a separate LCP observation in standard CrUX reporting. Meanwhile, INP and CLS could accumulate across the browsing session and be attributed to the first URL.

Google can now report experimental LCP, INP and CLS across hard navigations (full document loads) and soft navigations (JavaScript-driven view changes that Chrome recognises as navigations). That's a meaningful improvement in measurement coverage.

But there is a crucial distinction between measuring more of the experience and making the experience faster. When a customer waits for the initial application to load, that delay doesn't vanish because subsequent pages are quick.

And there's a less obvious consequence for search teams: could connecting people directly to the correct product make an SPA's aggregate Core Web Vitals look worse?

Why Fast Internal Navigations Change the Numbers

Once an SPA is running, it can reuse JavaScript, styles, data and other cached resources. Moving between product pages may therefore feel much faster than arriving from a search result on a cold load.

Google explicitly acknowledges this effect in its October announcement. Among Android origins where 75–100% of navigations are soft, the share rated Good for LCP rises from 26% under the existing metric to 87% under the experimental one. That's a change in the proportion of sites passing a threshold, not a 61% speed increase for any individual website.

The distinction matters because the browser now contributes more observations from the journey after the expensive first load. If technical performance stays identical, the mix of observations can still shift the reported result.

CrUX assesses Core Web Vitals using the 75th percentile (p75), not an average of page-load times. If three-quarters of recorded navigation observations are fast, an aggregate p75 can be fast even while every initial landing remains slow. See Google's methodology for Core Web Vitals thresholds.

The 1,000-Sale Thought Experiment: Browsing Versus Better SEO

Let's test the idea using two hypothetical ecommerce journeys. Both produce 1,000 completed transactions. They use the same SPA, the same technical implementation and the same checkout journey. We exclude checkout from the demonstration because we're isolating the product-discovery stage.

Scenario A — Four unnecessary navigations. A customer arrives on a general landing page and clicks through four more views before finding the product they actually want. Across 1,000 customers, that's 1,000 initial hard navigations plus 4,000 soft navigations: 5,000 navigation observations in our simplified model.

Scenario B — SEO lands customers directly on the product. Relevant, indexable product URLs appear for precise searches. The customer reaches the right product immediately and proceeds to purchase, without those four exploratory clicks. That's 1,000 hard-navigation observations in our simplified model.

Assume that every initial load has an LCP of 4.5 seconds and every soft navigation has an LCP of 0.7 seconds. Neither scenario involves a performance fix.

The paradox: Scenario B has removed four needless steps from each purchasing journey and generates the same sales, yet its aggregate p75 LCP is worse.

Important limitation: these are constructed navigation distributions, not predictions of live CrUX scores or samples of 1,000 real transactions. CrUX records eligible browsing activity across many visits, not just converters. Real results also depend on URL coverage, browser support, attribution, checkout navigations and the wider traffic mix.

Why This Is a Percentile Effect, Not an Average

A common mistake would be to average the 4.5-second landing load with the 0.7-second internal transitions, then claim Google uses that journey average. It doesn't.

For Scenario A, our 5,000 observations consist of 4,000 at 0.7 seconds and 1,000 at 4.5 seconds. The 75th percentile falls within the 4,000 fast observations, so the example's p75 is 0.7 seconds.

For Scenario B, all 1,000 observations are 4.5-second initial loads, so p75 is 4.5 seconds.

The underlying initial-load delay is identical. What changed is the proportion of fast and slow observations. This effect is most relevant to blended, aggregate distributions, particularly at origin level. At URL level, Google reports soft-navigation observations against the destination URL where eligible; a fast product-page transition does not simply become a faster measurement of the homepage.

Nor does this prove better SEO will cause worse rankings. It shows why a change in reported Core Web Vitals cannot automatically be read as a change in technical performance.

Could More Relevant Search Results Produce Worse CWV?

Good SEO should reduce friction between search intent and the right destination. If someone searches for a specific product, variant or size, an appropriate product URL should ideally answer that need directly.

Unnecessary detours through a homepage, category, brand listing and several product pages are not inherently signs of a better experience. Some customers enjoy browsing, comparing or discovering products; others know exactly what they want.

Under a blended navigation methodology, though, a longer SPA journey creates more chances to record the fast soft navigations that arrive after the initial application load. A shorter, more purposeful journey may produce fewer such observations.

That means genuine improvements in organic landing-page relevance, internal navigation efficiency or merchandising could alter the measured navigation mix and, in some circumstances, worsen aggregate p75 — even if page performance itself hasn't changed.

This isn't evidence that Google rewards irrelevant search results. It's a warning not to confuse journey length with website speed.

The Customer Who Bounces Is the One We Need to Understand

There's another potential bias. Imagine two customers arriving on the same slow SPA landing page.

One leaves after experiencing the initial delay. The other stays and opens ten more pages through fast soft navigations. If the hard-navigation LCP is captured for both, the first customer contributes a slow observation, while the second contributes that same slow observation plus up to ten subsequent fast ones.

The longer, successful browsing journey can therefore exert more influence on a blended navigation distribution than the shorter abandoned visit. If a visitor leaves before LCP is observed, that introduces an additional measurement-coverage consideration.

Whether slow landings actually cause abandonment should be tested, not assumed. But the commercial question is still the one that matters: are we losing customers before they've had a chance to experience the fast SPA navigation?

Delayed analytics initialisation can also make this harder to investigate. If measurement starts late, some early exits may never appear as reliable sessions or bounces in the analytics platform. Independent real-user monitoring can help close that gap.

What About INP and CLS?

The debate isn't limited to LCP, although LCP makes the clearest numerical example.

Previously, INP could reflect a problematic interaction from anywhere in a long SPA session, with the result attributed to the initial page. Under the experiment, interactions are evaluated within their respective navigations. CLS is also segmented by view, rather than being allowed to accumulate across the entire SPA session.

This is useful: it can make it easier to identify where responsiveness or visual instability occurs. But it also changes the distribution being reported. A before-and-after comparison can consequently show improvement even when no JavaScript, rendering or layout issue has been fixed.

Teams should keep looking for expensive main-thread work, late-loading UI, layout shifts and delayed interaction responses, regardless of whether a new blended score appears green.

How to Measure the Performance That Actually Matters

The right response isn't to reject Google's experimental metrics. It's to retain the context they cannot provide on their own.

1. Separate hard and soft navigations in real-user monitoring (RUM). Report initial landing-page LCP independently of subsequent SPA route changes.
2. Segment by organic landing-page type. Compare homepages, category pages, product pages and other entry routes, especially on mobile.
3. Connect performance with outcomes. Analyse engagement, exits, add-to-basket activity and conversion by initial-load performance. Control for traffic source, device and other relevant differences before inferring causation.
4. Monitor the share of soft navigations. An improved aggregate p75 may reflect a change in browsing behaviour as much as a technical change.
5. Evaluate technical changes against a consistent baseline. If you've improved critical CSS, hydration, rendering or JavaScript scheduling, compare like-for-like hard navigation cohorts rather than claiming success from a changed metric definition.
6. Keep checking the route detection. Chrome's soft-navigation detection depends on a user interaction, a URL change and a visible paint; it won't recognise every state change as a separate navigation.

This is the same measurement discipline needed when avoiding misleading performance metrics: a healthy-looking number is only useful if we know what it represents. The wider question of connecting measurement to business outcomes is equally important when weighing investment in technical improvements.

When Will the New Numbers Appear in Search Console?

The October 2026 soft-navigation Core Web Vitals are experimental. Google's existing stable CrUX metrics remain unchanged for now. The new data is available through the CrUX API, CrUX History API, BigQuery and CrUX Vis.

Google's stated target is to graduate the methodology in May 2027, subject to feedback, and switch Search Console to the new data after graduation. That's a plan, not an unconditional launch date.

This experimental period is a good opportunity to compare traditional and soft-navigation-inclusive results, document the difference and provide real-world feedback on cases where navigation mix could distort interpretation.

Frequently Asked Questions

Do soft navigation metrics make an SPA faster?

No. They expand measurement to include eligible in-app view transitions. Scores can improve without any code or infrastructure change.

Does CrUX average all page loads across a browsing session?

No. Core Web Vitals are assessed at the 75th percentile of the collected metric observations. Including additional, often faster soft navigations can change that distribution.

Can better SEO really worsen reported Core Web Vitals?

Potentially, for blended aggregate metrics. If relevant organic landings eliminate otherwise-fast SPA transitions, the mix of navigation measurements may change. This is a conditional thought experiment, not a claim that better SEO automatically reduces CWV or search rankings.

Should we still optimise initial landing-page performance?

Absolutely. New visitors must experience the hard navigation before they can benefit from fast internal browsing. Track that performance separately and connect it to meaningful customer outcomes.

Conclusion: Green Dashboards Are Not the Goal

Google has made meaningful progress towards measuring Single Page Applications more fairly. Fast internal navigation is part of the user experience and deserves to be counted.

But a blended aggregate can improve simply because users make more fast route transitions. Conversely, a more direct path from a highly relevant search result to the correct product can contribute fewer of those transitions.

That makes a better CrUX score different from a faster landing page, and both different from a better customer journey.

Teams should welcome the new data without treating green scores as permission to stop addressing slow initial loads. If we can remove loading delays and remove unnecessary customer journeys, that's a real win.

The goal isn't to manufacture more opportunities for fast measurements. It's to get the customer what they came for, quickly.