Chrome 151: Page Transitions in Single-Page Apps Can Finally Be Measured

Chrome 151, which reached the stable channel on July 28, 2026, added two new entry types to the browser’s performance timeline: soft-navigation and interaction-contentful-paint. Together they make it possible to measure the page transitions that happen after the initial load in single-page applications built with React, Vue or Next.js. In other words, exactly the part that has never shown up in any speed report until now.

The Problem: Classic LCP Only Measures the First Load

LCP (Largest Contentful Paint) measures when the largest piece of content on screen becomes visible, and it is part of the Core Web Vitals set. But what it measures is a single moment: the moment the document is first loaded into the browser.

In single-page applications this creates a serious blind spot. A user enters the site once, then moves from the product list to the product detail, on to the cart, and on to checkout. None of those transitions reload the document; the URL in the address bar is changed by JavaScript and the content is updated in place. As far as the browser is concerned you are still on the same page, so no new LCP measurement is taken.

The result: an e-commerce site scoring 100 in PageSpeed can take three seconds to render the cart, and that never appears in any report. What is more, those are precisely the screens that decide conversion — not the first load, but the transitions that follow it. And you cannot fix what you cannot measure.

Here is what that looks like on the business side: your analytics shows “drop-off is high at the cart step” and you try to guess why. Is the shipping fee putting people off, is the form too long, or is the screen simply arriving late? You could measure the first two; you could not measure the third. That is how teams end up trying design changes for months without noticing that the real problem was waiting time.

The Two New Entries in Chrome 151

According to the Chrome 151 release notes, these two entry types are added to the performance timeline “to track interaction-driven performance in single-page applications.” They do different jobs:

soft-navigation: In the words of the release notes, it reports “same-document history state changes initiated by interactions.” It does not just report them — it also establishes a new time origin. The practical meaning matters: subsequent performance data is now attributed to the route the user is actually on rather than the document’s initial URL. Time measured during a /cart transition no longer lands on the account of a home page opened hours earlier.

interaction-contentful-paint: This entry reports “new contentful paints within parts of the page modified by a user interaction.” Its purpose, as the release notes put it, is to help developers understand “interaction loading latency even across asynchronous fetch requests.” Roughly speaking: what LCP does, but triggered by a click instead of the initial load.

The relationship between the two is defined in WICG’s soft navigations draft: for a soft navigation to count, both a same-document URL change and a contentful paint attributable to the same interaction must occur. interaction-contentful-paint entries, on the other hand, are written to the timeline as they are detected, whether or not the interaction eventually results in a soft navigation. That distinction is useful: it means the time it takes for a modal or a filtered result to appear is measurable too, not only route changes.

Do You Have a Single-Page App?

Your technical team usually knows this already, but a short checklist helps:

• The tab’s loading indicator. If the spinner in the browser tab runs when you move to a page from the menu, you probably have a classic page load. If it never moves and the content changes in place, you have a soft navigation.
• The Network panel. Open developer tools, switch to the Network panel, then click a link. If you see a new “document” request, that is a full load; if you only see fetch/XHR requests, it is a single-page transition.
• The technology in use. If there is a client-side router such as React Router, Vue Router, Next.js App Router or Angular Router, transitions are soft navigations.
• Off-the-shelf platforms. Some e-commerce themes run product listing and filters like a single-page app while doing a full load on the cart and checkout steps. Hybrid setups are common; you have to look page by page.

How Do You Start Measuring?

These entries are observed with PerformanceObserver. It makes sense to check support first:

const supported = PerformanceObserver.supportedEntryTypes;

if (supported.includes('soft-navigation')) {
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // entry.name, entry.startTime, entry.entryType
      sendToAnalytics(entry);
    }
  }).observe({ type: 'soft-navigation', buffered: true });
}

if (supported.includes('interaction-contentful-paint')) {
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      sendToAnalytics(entry);
    }
  }).observe({ type: 'interaction-contentful-paint', buffered: true });
}

buffered: true lets you also receive entries that occurred before the observer was registered, which you need in order not to miss early transitions. When sending the data, using navigator.sendBeacon keeps the request from being dropped as the user leaves the page.

On the practical side, plan three things up front: which route you attribute an entry to (the route template, not the URL — something like /product/:id), your sampling rate (collecting data from every single visitor creates unnecessary cost), and where the data will accumulate. Your own endpoint works; so does your existing analytics tool.

What Do You Do Once the Data Arrives?

The data on its own fixes nothing; you have to know what you are looking for:

• Look at the distribution per route. Not the average — the 75th percentile. If the home page is fast but the /cart transition is slow, the problem is not site-wide, it is on one route.
• Match it to your funnel. If the step where drop-off rises and the route where transition time grows are the same, you are holding a measurement rather than a guess.
• Isolate why the slow route is slow. Is the transition waiting on a data request, or is that route’s JavaScript bundle being downloaded at that moment? The first calls for prefetching or caching, the second for code splitting.

Two Small but Useful Changes in the Same Release

Under the performance heading, Chrome 151 carries two more changes that are not directly about single-page applications but are practically useful.

The first is ignoring duplicate navigations. According to the release notes, an ongoing navigation is no longer canceled by an identical navigation started right after it. The scenario is a familiar one: the user clicks a link or button twice in a row, the first request is canceled halfway through, and everything starts over. This change prevents the network requests wasted on accidental double-clicks.

The second is measurable cross-origin redirect timing. Servers can now opt in to having their redirects measured by the destination origin of a navigation. For teams that use campaign links, shortened URLs or ad redirects, this finally means answering the question “how much of the time between the click and the page appearing is lost in the redirect?” with a number.

Limits

A few points are worth stating up front. These entries are collected on the browser side; data only comes from browsers that support them, so the picture you get does not cover all of your traffic. The Chrome 151 release notes contain no statement tying these entries to Core Web Vitals thresholds or to search ranking; for now they are diagnostic measurement tools. Soft navigation detection also relies on a heuristic: an interaction, a URL change and a contentful paint have to occur together. Transitions that do not satisfy those conditions may not be recorded.

Even so, this picture is far better than having no data at all. We shared the methods behind improving first-load performance in our post on how we reached a PageSpeed score of 100; with Chrome 151, the same discipline can now be applied to the transitions that come after that first load.

Where to Start

A sensible order looks like this: first map out which parts of your site run on single-page logic, then instrument the three most critical transitions (product detail, cart, checkout), collect data for two weeks, pick the slowest route and isolate its cause. Trying to measure everything at once produces a pile of data nobody uses.

To measure your site’s transition performance and fix the slow routes, take a look at our website speed optimization service — and if you would like to talk through your situation, you can reach us via our contact page.