Chrome measures every route in your site separately now

Chrome 151 began rolling out to stable on 28 July 2026, carrying two new entries in the performance timeline: soft-navigation and interaction-contentful-paint. If any part of your site swaps content on a click without a full page load, Chrome now treats each of those route changes as its own measurable page.

That reads like a technical footnote. It changes what your existing numbers mean, and it can make them look worse while your site gets no slower.

What counts as a soft navigation

Chrome only records one when three things are true at once. A user action started it. The visible URL changed. Something new painted on screen. Miss any one and it does not register, so a router that swaps content on a timer is ignored, and so is a URL change with no repaint.

Until now, none of this existed as far as measurement went. Your React or Next app loaded once, LCP and CLS were stamped against that first load, and every route after it was dark. Someone could land on the homepage, click into services, open a case study, then reach the contact page, and only the homepage was ever graded.

Each of those routes now gets its own LCP, its own layout shift accounting, and its own interaction window.

Why your percentiles can drop with nothing broken

Core Web Vitals are judged at the 75th percentile of recorded experiences, not the average. That single fact is what makes this update land the way it does.

You are about to start recording a large group of experiences that were previously invisible. In-app routes are usually slower than the first load, because the first load was server rendered with data already in the HTML, and the route change has to fetch data after the click, then paint. So the newly counted experiences sit at the slow end, and the 75th percentile of the whole set moves toward them.

Your site is exactly as fast on 30 July as it was on 27 July. You are just counting the part you were not counting.

Brief this before it shows up in a dashboard, not after. A marketing team that reports a Core Web Vitals decline they cannot explain loses credibility on every performance conversation that follows.

The double count almost nobody has checked

The web-vitals library shipped v6 on 21 July 2026 with native soft-navigation support. Plenty of sites already run a hand-rolled virtual pageview shim next to it, added years ago precisely because the browser would not report route changes.

Run both and you double count. Worse, they do not agree on boundaries, so interaction timing gets attributed to different routes by each mechanism, and your numbers stop reconciling with themselves.

Three things to do before you upgrade:

1. 1.Search your analytics implementation for any manual route-change hook that reports LCP, CLS or INP. That is your shim.
2. 2.Stamp the browser version and the web-vitals version onto every beacon you send. Without that stamp, no historical comparison survives this change.
3. 3.Run the old and new paths in parallel for a fortnight, in separate report streams, and compare before you cut over.

Two implementation details that will bite

TTFB is reported as 0 for a soft navigation. There is no document request, so there is nothing to time. If your reporting averages TTFB across all recorded navigations, every route change now drags that average toward zero and your server looks faster than it is. Filter soft navigations out of TTFB reporting entirely.

The API also changed shape late. The largest interaction contentful paint value was a static attribute, and it is now a method call. Code written against early origin-trial examples will silently return undefined rather than throw, which is the worst kind of failure because the beacons keep flowing and the values are empty.

What Google actually does with this

Undetermined, and Google has said so. How the Chrome User Experience Report will handle soft navigations has not been settled, which means for now your field data knows things Google's grading does not.

That gap is useful rather than annoying. You get a period where you can see the per-route picture, fix the worst routes, and arrive at whatever Google decides with the work already done. The alternative is finding out through a ranking report.

The practical move for a multi-page marketing site

If your site is server rendered and every nav click is a real document request, none of this touches you today. Check anyway, because the pattern creeps in: a filtered product listing, a multi-step form that pushes state to the URL, a case study gallery with deep links. Any of those can qualify as a soft navigation without anyone deciding to build a single-page app.

If your site is an app shell, pull a list of your top ten routes by entry volume, and expect the ones behind a data fetch to be your worst performers. They usually are, and they are usually the ones with the enquiry form on them.

Measurement caught up with how sites are actually built. Your reporting has about a month to do the same.