Soft navigations: The future of seamless browsing

In the ever-evolving world of web standards, a new experimental feature is quietly reshaping how browsers perceive navigation: Soft Navigations. While still in the early stages, this concept has the potential to redefine user experience metrics, improve performance monitoring, and better align browsers with the behavior of modern web applications.

Let’s dive into what soft navigations are, why they’re important, and how you can start exploring them today.

What are soft navigations?

Traditionally, browsers have treated navigation as a page load event, clicking a link or submitting a form triggers a full page reload or navigates to a new document. However, with modern JavaScript frameworks like Angular, React, and Vue, most transitions occur without full-page reloads. This is where soft navigations come into play.

A soft navigation is a navigation event that changes the visible state or URL of a page without triggering a traditional page load. Think of route changes in a Single Page Application (SPA) or client-side DOM rewrites that behave like real navigation to the user but aren’t recognized as such by the browser.

Chrome’s definition

According to the Chrome Developers documentation, a soft navigation is identified when the following conditions are met:

• User Interaction: The navigation is initiated by a user action.
• URL and History Change: The navigation results in a visible URL change to the user and a history change.
• DOM Change: The navigation results in a DOM change.
• These heuristics aim to detect navigations that feel like traditional page loads to users, even if they don’t involve a full page reload.

Why do they matter?

Up until now, SPAs have posed a challenge to browser-based performance tracking and web APIs like the Navigation Timing API. Because the browser doesn’t recognize internal route changes as navigations, metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP) are only calculated for the initial load.

With soft navigations, the browser can now detect and label these in-page navigations, allowing for more accurate performance metrics, session tracking, and user behavior analytics.

With soft navigations:

• Core Web Vitals can be measured per view, not just per full reload.
• Analytics tools gain visibility into the true user journey across SPA routes.
• Accessibility and navigation history behave more consistently.
• Performance metrics like LCP and INP can be tied to the correct navigation context using the new navigationId attribute.
• This marks a major step toward parity between SPAs and traditional multi-page apps in terms of browser observability.

How this powers Coralogix’s RUM for SPAs

Supporting Single‐Page Applications (SPAs) in our RUM product unlocks a whole class of performance data that today simply goes unmeasured whenever an SPA client navigates without triggering a full page reload.

Here’s how SPA support will boost our offering.

Capture core web vitals on virtual page-views

Problem today: Core Web Vitals (LCP, FID, CLS, etc.) are only reported on the initial page load. In an SPA, subsequent “pages” (routes) change via JavaScript without firing the browser’s standard load events, so we miss vital signals.

With SPA support: We can use the Performance Observer API to emit synthetic “page-view” events on each route change. That means every view transition, profile page, dashboard, settings, gets its own set of Web Vitals.

Benefit: Users regain Google-standard p75 benchmarks and histograms for every section of their app, enabling granular dashboards, alerts, and direct comparisons to industry thresholds.

Measure and alert on per-route loading metrics

Problem today: Without SPA instrumentation, you only see “initial” load times; slowdowns in subsequent views go unnoticed until a user complains.

With SPA support: Automatically capture metrics like Time to First Byte (TTFB), and custom performance marks on each view change.

Benefit: Create SLOs and alerts per “logical page” (e.g. checkout → order confirmation), so teams get notified if the payment page LCP drifts above 2.5 s, even though the overall app was already loaded hours ago.

Enhanced diagnostic context

Problem today: Errors or slow‐loading components recorded during navigation lack timing metadata tied to a route change.

With SPA support: Attach route‐change timestamps, performance marks and resource‐loading details to every error or breadcrumb.

Benefit: When a slow third-party script delays the search page’s interactivity, you’ll see exactly which script, how long it took, and which virtual route was impacted, streamlining triage.

Better user-level journeys and funnel analysis

Problem today: Funnels crossing multiple SPA routes don’t get duration splits.

With SPA support: Track and timestamp each step in a multi‐step process (e.g., “start signup” → “email verification” → “set password”) as discrete views, measuring drop-off and time between steps.

Benefit: Identify that 40% of users stall for over 5 s on the verification screen—perhaps due to a delayed API call—so product and engineering can optimize exactly where it hurts the most.

How does it work?

Soft navigations are currently an experimental feature available behind a flag in Chromium-based browsers like Chrome and Edge. Instead of relying on traditional page loads, the browser uses a heuristic to determine when a user experiences a meaningful navigation, even if no new document is loaded.

Once enabled, Chrome tracks soft navigations using the following signals:

• User interaction — A click or tap starts the navigation.
• History API use — The app updates the URL using pushState() or replaceState().
• Substantial DOM mutation — The main content area changes, often involving reflows or visible re-renders (not just minor DOM edits).
• When these conditions are met, the browser logs a soft navigation entry via the PerformanceNavigationTiming API — just like it would for a full page load.

Trying it out

If you’re curious to see soft navigations in action, you can enable the feature in Chrome:

Open Chrome and go to chrome://flags.
Search for #enable-experimental-web-platform-features.
Enable it and restart the browser.

Once enabled, you can inspect soft navigations using the PerformanceObserver API:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Limitations and what’s next

As of mid-2025, soft navigations are still experimental and only supported in Chromium browsers behind a flag. The heuristics are not perfect, and some transitions might be missed or falsely identified.

However, browser vendors and the W3C are actively discussing how to formalize this behavior into a standard. A future where browsers fully understand the nuances of SPAs is getting closer.

Final thoughts

Soft navigations reflect a much-needed alignment between browser behavior and how modern web apps actually work. As SPAs and dynamic interfaces dominate the web, treating route changes as first-class navigation events will improve analytics, performance monitoring, and the overall developer experience.

If you’re building or maintaining an SPA, this is a development to watch closely. And if you enjoy exploring the future before it lands, go ahead, flip the flag, and start experimenting.