Written by Guillermo Fernández
Index
Chrome has introduced a new API in the browser, designed to improve how performance and user experience are measured during smooth navigations, or “soft navigations.” Its main goal is to measure the Core Web Vitals optimally and consistently in Single Page Applications (SPAs).
For now, it’s an “Origin Trial”, an experimental feature available starting from Chrome 139, with its evaluation period running until March 2026.
Therefore, this API’s metrics currently have no impact on Core Web Vitals.
A smooth navigation occurs when a navigation interaction (for example, clicking a link) is processed by JavaScript, updating the content on the current page without requiring a full reload.
A common example is infinite scrolling: new paginated content is injected into the page’s DOM without a full page reload, though the browser URL may still update.
A smooth navigation also takes place within a Single Page Application, where the entire site behaves this way and functions without full page reloads.
Why is this API necessary?
The need for such an API arises from the difficulty of measuring Core Web Vitals efficiently on SPA sites. Currently, measurements for these sites only occur during hard navigations (the first load), and smooth navigations neither reset the metrics nor count as new page loads.
This means that LCP can only be measured on the initial load of an SPA, while CLS/INP are cumulative metrics throughout the session and are attributed to the originally loaded URL, leading to inaccurate measurements.
This happens because Chrome currently lacks a consistent way to identify a navigation event within an SPA, interpreting everything as interactions within the initially loaded URL.
If, for example, we click the “create post” button on our LinkedIn profile, a small pop-up window appears to enter post details — without reloading the page and without updating the browser’s URL. In this case, is it a navigation or an interaction? Should LCP be measured on the pop-up window?…
According to Chrome, this currently counts as an interaction, and according to the Soft Navigations API… it does too. The difference is that Chrome currently treats everything as an interaction — it has no mechanism to distinguish between the two. This is one of the main reasons this API was developed: to establish rules (heuristics) that can standardize what is considered a navigation versus an interaction.
The closest existing mechanism in Chrome is the intercept() method of the Navigation API, but it isn’t a valid approach for SPA measurement for the following reasons:
- The use of the
intercept()method is not mandatory, meaning many sites may use the Navigation API but notintercept(), requiring a large number of SPAs to rewrite parts of their code. - The behavior of
intercept()is customizable, so its use may vary from one implementation to another. - The Navigation API cannot make a true distinction between navigations and interactions.
The Soft Navigations API addresses this issue by standardizing what is considered a navigation and distinguishing it from an interaction. According to the API, a navigation occurs when:
- The user performs an interaction
- That interaction results in a DOM modification and a meaningful render
- That interaction also triggers a URL update
Additionally, because this API essentially establishes a standardized behavior within the browser, SPA developers wouldn’t need to modify their existing code for the API to measure correctly—it can work across existing implementations.
In conclusion
If you manage a Single Page Application and struggle to measure performance and user experience, the Soft Navigations API is a very promising improvement.
Whether for obtaining reliable CrUX data samples or for third-party RUM implementations, this API will allow you to consistently identify issues users encounter.
For now, it remains an experimental feature, but you can test it locally in Chrome by visiting: chrome://flags/#soft-navigation-heuristics
