Core Web Vitals is starting to measure in-app route changes too

On the Next.js sites I build, I often tell clients the same thing: fast first load is not enough on its own, the site also has to feel fast when a visitor moves to another page from the menu. The Chrome team has taken a step on exactly this. According to the announcement on web.dev dated 13 October 2026, CrUX now publishes experimental Core Web Vitals metrics that include soft navigations.

What is a soft navigation?

On a classic site, every link you click makes the browser load a new page. On sites built like single page apps, such as Next.js sites, most transitions happen in JavaScript without a full reload. These are called soft navigations. Until now Core Web Vitals mostly looked at the first load, so delays and shifts during in-app transitions could fall outside the measurement.

What changed

• The new experimental metrics measure LCP, INP and CLS on full page loads and on route changes made in JavaScript.
• The data is available from the October 2026 CrUX release through BigQuery, the CrUX API and the CrUX History API.
• The web platform API that makes this measurement possible shipped in Chrome 151.
• Google's stable Core Web Vitals scores stay as they are for now while the experimental metrics are evaluated.

The Chrome team expects most classic multi-page sites to see the same or very similar results. Sites that lean heavily on client-side transitions are expected to see a difference.

When does this concern you?

If your site is built the classic way, like most WordPress sites, very likely nothing changes. If you use Next.js or a similar setup, especially with filtered product lists, infinite scroll or modal windows, slow transitions may show up in the data for the first time. These metrics are still experimental and their definitions may change, so I don't recommend putting them in contracts as targets yet. It is a good time to know what you are looking at, though.

What slows transitions down on Next.js sites?

The most common cause I see, on my own projects and on sites I take over, is leaving too much work to the browser when the page changes. If every transition downloads and runs a large JavaScript bundle, the visitor clicks the menu and sees nothing happen for a moment. That is the kind of delay INP measures.

The second cause is third-party tags. Analytics, advertising and chat tools can fire again on every route change and keep the main thread busy. The third is components that move as the new page's content arrives: images without a set height, banners that load late, or a product grid that jumps down when filter results come in. Those show up in CLS.

Most of these problems can appear on first load too, but soft navigation measurement will make them visible inside the app as well. So sites we have been comfortable with because "the first load is fast" now have a new place to look.

What you can do now

1. Measure menu and product list transitions per route with a real user monitoring tool.
2. Compare the experimental soft navigation fields in the CrUX API with your current LCP, INP and CLS results.
3. Test delays and layout shifts in filtering, infinite scroll, modals and client-side route changes.
4. Where transitions are slow, cut down heavy JavaScript, third-party tags and large image components.
5. Wait for the metrics to become stable before turning experimental data into a contractual performance target.

If you'd like to measure your Next.js site's transitions together, leave me a message and we'll decide which pages to start with.

Sources

• Experimental soft navigation metrics now available in CrUX, web.dev / Chrome team, 13 October 2026