Core/Dash Dimension: Navigation Type

Dimension: Navigation Type (nt)

Every page view in your CrUX data carries a navigation type. It tells you how the browser loaded the page, which determines which browser systems were involved: the network stack, the back/forward cache, the prerender pipeline, or a session restore. CoreDash exposes this as the nt dimension so you can filter and compare Core Web Vitals across each navigation context separately.

The data comes from the PerformanceNavigationTiming API, specifically the type property. You read it with performance.getEntriesByType("navigation")[0].type. Chrome reports this value alongside every web vitals measurement sent to CrUX, and CoreDash stores and indexes it so you can segment without writing any custom instrumentation.

Why Navigation Type matters

Aggregating LCP or INP across all navigation types produces a number that is technically correct and practically misleading. A back/forward cache hit completes in milliseconds. A cold navigate waits on DNS, TCP, TLS, and TTFB. If 20% of your sessions are bfcache hits, they pull your p75 LCP down and make a real problem on fresh navigations harder to see.

The reverse is also true. If bfcache is broken on your site, back/forward sessions will perform as badly as fresh navigates. Without segmenting by navigation type, you will never notice, because the aggregate stays stable.

Prerender is the most dramatic case. A correctly prerendered page should show an LCP close to zero, because rendering finished before the user even clicked the link. If your prerendered pages show normal LCP numbers, the Speculation Rules configuration is wrong and the prerender is either not triggering or being discarded before use.

The Navigation Types

navigate

A standard navigation: the user typed a URL, clicked a link from another site, or followed a redirect. This is a full page load with no caching shortcuts. The browser goes through the complete request pipeline including DNS lookup, connection establishment, and full resource loading. In CoreDash data, navigate accounts for roughly 65% of sessions. It is your baseline. Every other navigation type should be judged against how it compares to navigate.

reload

The user pressed F5, clicked the browser's reload button, or your code called location.reload(). The browser sends revalidation requests for cached resources, which means TTFB often looks worse than a navigate despite the user being on the same page. If your reload TTFB is dramatically higher than navigate TTFB, your cache headers are triggering revalidation on every reload instead of serving stale content. Approximately 10% of sessions are reloads in typical CoreDash traffic.

back_forward

The user pressed the browser's back or forward button. If the back/forward cache (bfcache) is working, this is the fastest navigation type possible. The browser restores the page from memory with no network requests at all. LCP for a bfcache hit is effectively the time to paint from memory, which is near-instant.

If your back_forward metrics look similar to navigate, bfcache is not working. The most common causes are unload event handlers, Cache-Control: no-store response headers, and open IndexedDB connections that were not closed before navigation. CoreDash data puts back/forward at around 20% of sessions, making this a high-leverage fix.

prerender

The page was loaded in the background using the Speculation Rules API before the user clicked the link. When the user does click, the prerendered document is activated instantly. LCP for a correctly activated prerender is close to zero because all rendering work finished before the navigation event.

If your prerender LCP looks normal, one of three things happened: the prerender was discarded before activation, the speculation rule targeted the wrong URLs, or the page uses headers or JavaScript that prevent prerendering. Approximately 3% of CoreDash sessions are prerender activations, but that share rises quickly once Speculation Rules are deployed.

restore

The tab was restored after the browser was closed or the tab crashed. The browser reloads the page from scratch, but the session is considered a restore rather than a fresh navigate. Performance is similar to a cold navigate. This accounts for roughly 2% of sessions and is rarely the focus of optimization work, but it is worth monitoring if you have users on unstable browser sessions.

Debugging Workflow

1. Compare navigate LCP against your overall LCP target. This is your ground truth for fresh load performance. If navigate is already passing, your problem is elsewhere.
2. Check back_forward against navigate. If they are close, bfcache is broken. Open Chrome DevTools, go to the Application panel, and run the bfcache test. The DevTools output will list exactly which features or headers are blocking bfcache eligibility.
3. Check prerender LCP. If it is above 200ms, the prerender pipeline is not delivering. Verify your Speculation Rules JSON is valid, check that the target pages return no blocking logic, and confirm activations are being counted in Chrome DevTools under Speculation Rules.

Engineering Rule of Thumb

• navigate: Should meet your LCP threshold through normal optimization: fast TTFB, fetchpriority="high" on the LCP image, no render-blocking resources.
• back_forward: Should be 10 to 20 times faster than navigate. If not, bfcache is broken.
• prerender: Should show LCP under 200ms. If not, your Speculation Rules are misconfigured.
• reload: TTFB should not be dramatically worse than navigate. If it is, fix your cache revalidation headers.

Navigation Type is the dimension that separates "how is my page performing?" from "how is my page performing under each browser loading strategy?" That distinction is the difference between guessing and debugging.