Soft Navigation vs Page Load Metrics in CrUX

Soft navigation metrics and traditional page load metrics differ in what they measure: page load metrics capture the initial loading experience of a document, while soft navigation metrics capture the experience of navigating within a single-page app (SPA) or after a client-side view change. In Chrome UX Report (CrUX), this means you now get two sets of Core Web Vitals: one for the initial load and one for each soft navigation, with the latter reflecting how users perceive transitions and content updates after the page is already open.

Background: Why Soft Navigations Appeared

Traditional page load metrics were designed for multi-page websites where every user action loads a new HTML document. But modern web apps often use client-side routing: the URL changes and the view updates without a full page reload. For these experiences, the old metrics missed most of the user journey. A user could tap through a product list, open a detail page, and add an item to a cart—all without a single page load. The only signal CrUX had was the initial load, which might be fast but says nothing about the sluggish transitions that follow.

Google introduced soft navigation reporting in CrUX to fill that gap. A soft navigation is a same-document navigation triggered by the History API (pushState or replaceState) or by the browser’s same-document navigation features. It represents a user-perceived change of content within the same page. By tracking these, CrUX can report Core Web Vitals (LCP, CLS, INP) for each soft navigation, giving site owners a view of the entire app experience, not just the first paint.

How Soft Navigation Metrics Work in CrUX

When a user performs a soft navigation, the browser starts a new navigation entry. The metrics are then measured relative to that entry:

• LCP (Largest Contentful Paint) for a soft navigation is the time from the soft navigation start until the largest content element in the new view is painted.
• CLS (Cumulative Layout Shift) is measured for the session window that follows the soft navigation, ignoring shifts that occurred before it.
• INP (Interaction to Next Paint) is measured for interactions that occur during the soft navigation’s lifecycle, with the same 75th percentile aggregation as for page loads.

These soft navigation metrics are reported separately in CrUX. The CrUX API and BigQuery now include fields like soft_navigation_lcp, soft_navigation_cls, and soft_navigation_inp. In the CrUX dashboard, you can see them alongside the traditional page load metrics. The key difference is that page load metrics describe the experience of the initial document load, while soft navigation metrics describe the experience of subsequent view changes.

How to Choose: Which Metrics Should You Track?

You should track both, but they serve different purposes. Page load metrics are still essential for understanding the entry experience—how fast your site becomes interactive when a user first arrives. Soft navigation metrics are critical for SPAs and apps with client-side routing, because they reveal the quality of the in-app experience. If your site is a traditional multi-page site with full reloads on every link, soft navigation metrics will be rare or non-existent, and page load metrics remain the primary signal.

For a hybrid site—some pages are traditional, some are SPAs—you need to look at both to get a complete picture. The CrUX data will show you which type of navigation dominates for each URL pattern. Use page load metrics to optimize the initial entry, and use soft navigation metrics to optimize the internal transitions.

Common Problems and Misconceptions

A common misconception is that soft navigation metrics replace page load metrics. They don’t; they complement them. Another issue is that soft navigation metrics are only reported when the browser detects a soft navigation. If your SPA uses hash-based routing (e.g., #/about) without the History API, the browser may not classify those as soft navigations, and you’ll see few or no soft navigation entries. To get accurate soft navigation data, use the History API or ensure your router uses pushState.

Another problem is that soft navigation LCP can be tricky to measure if the new content is inserted dynamically. The browser’s LCP algorithm looks for the largest paint in the viewport, but if you update the DOM asynchronously, the timing can be affected. Similarly, CLS during soft navigations can be inflated if you insert content without reserving space. It’s important to test with real user monitoring (RUM) to see how your specific implementation behaves.

Comparison: Page Load vs Soft Navigation Metrics

The table below summarizes the key differences:

• Trigger: Page load starts with a document request; soft navigation starts with a same-document URL change.
• Measurement window: Page load metrics cover the initial load; soft navigation metrics cover the period after a view change.
• Relevance: Page load metrics matter for all sites; soft navigation metrics matter mainly for SPAs and client-side routed sites.
• Reporting: In CrUX, they are separate dimensions; you can filter by navigation type.
• Optimization: Page load optimization focuses on server response, render-blocking resources, and initial HTML; soft navigation optimization focuses on client-side JavaScript execution, data fetching, and DOM updates.

In practice, a site might have a fast page load but poor soft navigation scores if the client-side code is heavy. Conversely, a site might have a slow initial load but fast soft navigations if the server is slow but the client-side app is well-optimized.

Costs and Practical Considerations

Implementing soft navigation metrics has no direct monetary cost, but it does require engineering effort. You need to ensure your router uses the History API, and you may need to add custom instrumentation if you want to track soft navigations that the browser doesn’t automatically detect. There’s also a potential performance cost: adding extra event listeners or measuring code can add overhead, though it’s usually negligible.

From a data perspective, CrUX only reports soft navigation metrics for origins that have enough traffic to be included in the dataset. Small sites may not have sufficient data for soft navigation-specific percentiles. In that case, you can still use field data from your own RUM to get the same insights.

Safety and Accuracy in Measurement

When measuring soft navigations, accuracy is paramount. The browser’s definition of a soft navigation is specific: it must be a same-document navigation that changes the URL via the History API or a fragment navigation. If you use a framework that does not trigger these mechanisms, your soft navigation metrics will be missing. Also, be aware that some browser extensions or ad blockers can interfere with navigation tracking, though this is rare.

For accurate CrUX data, ensure your site is served over HTTPS and is publicly accessible. CrUX collects data from real Chrome users who have opted in to syncing their browsing history. If your site is behind a login or a paywall, CrUX may not have data for those pages, because the crawler can’t access them. In such cases, rely on your own RUM to measure soft navigations.

Alternatives and Complementary Tools

If CrUX doesn’t provide enough detail, you can use the Navigation API (when available) or the PerformanceObserver API in your own RUM to track soft navigations. Tools like Web Vitals JS library can be configured to report soft navigation metrics. For lab testing, you can use Puppeteer or Playwright to simulate soft navigations and measure performance in a controlled environment.

Another alternative is to use the performance.softNavs interface in Chrome, which provides a list of soft navigation entries. This is more granular than CrUX and allows you to debug individual navigations. However, it’s not available in all browsers, so CrUX remains the standard for cross-browser field data.

Frequently Asked Questions

Q: Do soft navigation metrics affect my Core Web Vitals score in PageSpeed Insights?
A: Yes, PageSpeed Insights now shows soft navigation metrics separately. The overall Core Web Vitals assessment is still based on the page load metrics, but soft navigation metrics are displayed as additional data. Google has indicated that soft navigation metrics may be incorporated into the overall assessment in the future.

Q: My SPA uses hash-based routing. Will soft navigation metrics be reported?
A: Not reliably. Hash changes are not considered same-document navigations by the browser’s navigation API. To get soft navigation metrics, switch to the History API (pushState) or ensure your router uses it. Otherwise, CrUX will likely report no soft navigation data for those routes.

Q: How do I see soft navigation metrics in CrUX?
A: In the CrUX dashboard, you can filter by navigation type. The CrUX API also supports a navigation_type parameter. In BigQuery, the tables include a column for navigation type, which can be ‘reload’, ‘navigate’, ‘back_forward’, ‘prerender’, or ‘soft_navigation’.

Q: Can I use soft navigation metrics for a traditional multi-page site?
A: Only if your site uses client-side transitions (e.g., with a framework like Turbolinks or a custom PJAX implementation). If every link causes a full page load, you won’t have soft navigations, and you should focus on page load metrics.

Q: What is the difference between soft navigation and a fragment navigation?
A: A fragment navigation is a change to the URL fragment (e.g., #section). The browser treats it as a same-document navigation, but it does not necessarily trigger a soft navigation metric unless it causes a user-perceived content change. The browser’s soft navigation detection is based on the History API and the resulting DOM changes, not just the URL fragment.

Q: How can I improve my soft navigation LCP?
A: Focus on optimizing the JavaScript that renders the new view. Minimize the amount of DOM manipulation, use code splitting to load only the necessary components, and prefetch data for the next view when possible. Also, ensure that the largest content element in the new view is not delayed by lazy loading or asynchronous rendering.

Related

• How to Compute Score Percentage in Excel
• How to Find P-Value: Step-by-Step Guide
• How to Find T Score: Step-by-Step Guide

in t | Finish time | min | 50 | 0
in d | Distance | km | 10 | 0
out pace | Average pace | min/km | t / d | 2
out speed | Average speed | km/h | d / (t / 60) | 2