Chrome is shipping a Soft Navigations API that solves a measurement problem the entire single-page-app era has quietly lived with: Core Web Vitals only ever counted the very first page load. Every route change after that, the taps and clicks that make up most of a real session in a SPA, was invisible to the metrics Google uses to rank pages. The new API teaches the browser to recognize these in-app navigations and measure LCP and INP for each one, turning a first-load-only snapshot into a picture of the whole session.

  • A soft navigation is an in-app route change (a click that swaps views) without a full document reload.
  • Until now, Core Web Vitals like LCP were captured once, on hard load, so SPA route changes went unmeasured.
  • The Soft Navigations API lets the browser attribute LCP and INP to each soft navigation, exposed via the Performance APIs used by RUM tools.
  • It arrived as part of Chrome's broader "agentic web" and performance push announced at Google I/O 2026.
Where Core Web Vitals stopped measuring in a SPA A session timeline: the hard load is measured, then three soft navigations go unmeasured under the old model. The Soft Navigations API measures each of them. A TYPICAL SPA SESSION Hard load measured Route A Route B Route C old model: invisible Soft Navigations API measures A, B and C too Most of a real SPA session happens after the one load the old metrics saw. genztech.blog
Fig 1 The blind spot: Core Web Vitals saw one load, then stopped, even as the user kept navigating inside the app.

What is a soft navigation?

When you click within a traditional website, the browser fetches a new document and reloads: a hard navigation. In a single-page app, that same click is intercepted by JavaScript, which swaps the view and updates the URL without a full reload: a soft navigation. It feels like a page change to the user, but to the browser's performance instrumentation it historically looked like nothing happened, because the metrics were wired to the document-load lifecycle. The Soft Navigations API gives the browser a heuristic to detect these in-app transitions and start a fresh measurement window for each.

RelatedECMAScript 2026 Is Finalized: What the 17th Edition Means

Why did this blind spot matter?

Because it made SPA performance data misleading in the direction that flattered developers. A framework-heavy app could post a decent first-load LCP and a clean INP, then subject users to sluggish route changes that never showed up in any Core Web Vitals report. Teams optimized for the one measured moment and flew blind on the dozens of interactions that defined the actual experience. For a metric set Google uses as a ranking input and that RUM vendors sell dashboards around, measuring only the first load of the web's most common app architecture was a real gap.

What changes for developers?

Analytics and RUM tools can now attribute LCP and INP to specific in-app routes, which means a slow view is finally a diagnosable data point rather than a user complaint you cannot reproduce in metrics. That reshapes optimization priorities: instead of pouring effort into shaving the initial bundle, teams can see which route transitions are janky and fix those. It also raises the bar, because performance debt that used to hide after the first paint becomes visible and, plausibly, ranking-relevant over time.

AspectWith Soft Navigations APIOld model
Hard loadMeasuredMeasured
Route changesMeasured (LCP, INP)Unmeasured
DiagnosisPer-route attributionFirst-load only
Optimization focusWhole sessionInitial bundle

What are the caveats?

Soft navigation detection is heuristic, so it will not perfectly classify every framework's routing, and edge cases, modal-heavy UIs, nested routers, partial view swaps, may be measured inconsistently across sites. It is also a Chrome-led capability, which means cross-browser parity is not guaranteed and comparisons should account for that. As with any new performance signal, the data is only as good as the instrumentation reading it, so RUM tooling and framework integration will determine how quickly the win reaches real dashboards.

RelatedEdge 150 Now Lets You Sign In With a Google Account

What to watch · next releases
  • RUM adoption. The API matters once analytics vendors surface per-route LCP and INP by default; watch for that rollout.
  • Ranking weight. If soft-navigation vitals eventually feed search signals, SPA performance debt gets a real SEO price.
  • Framework support. React, Vue, and Angular router integrations will decide how clean the attribution is in practice.

Our take

This is one of those unglamorous platform fixes that quietly changes incentives. For years the web's dominant app pattern got graded on a single moment and coasted afterward, and developers rationally optimized for the test. Measuring the whole session removes that loophole. The apps that were genuinely fast will keep looking good, the ones that leaned on a fast first paint to mask sluggish navigation will finally have the receipts. That is healthy, even if it makes some dashboards look worse before teams fix what they now can see.

Why is INP the real prize?

Largest Contentful Paint gets the headlines, but the metric that soft navigations most improve is Interaction to Next Paint, the responsiveness measure Google made a core vital. INP is fundamentally about how snappy an app feels while you use it, which is exactly the phase of a SPA session the old model ignored. By attributing INP to individual in-app routes, the API turns "the app feels laggy sometimes" into a specific, reproducible number tied to a specific view, and that is what makes it fixable. The detection is heuristic and cross-browser parity is not guaranteed, so treat the early data as directional, but the direction is unambiguous: responsiveness debt that used to hide after the first paint now has a name and an address.

Primary sources

Original analysis by GenZTech. Reporting via Chrome for Developers.