Core/Dash Dimension: Navigation Origin
See whether your visitors arrive from the same domain or from external sources, and how that split shapes your Core Web Vitals.
What Navigation Origin measures
The Navigation Origin dimension splits your field data into two groups:
- Same Origin (1) — the previous page was on the same domain.
- Cross Origin (2) — the user arrived from a different domain, a search engine, a social platform, or typed the URL directly.
This distinction matters because the browser's starting conditions are completely different in each case. A same-origin navigation can reuse an existing connection, draw on the HTTP cache for subresources, and benefit from any prefetching your site has set up. A cross-origin navigation starts from scratch.
Why cross-origin navigations are slower
When a user clicks a link from an external site, the browser has work to do before it can even request your HTML:
- DNS lookup — resolve your domain to an IP address.
- TCP handshake — open a connection to your server.
- TLS negotiation — complete the HTTPS handshake.
Together these steps typically add 200 to 500 ms on a mobile connection before the first byte of your page has been requested. That cost shows up directly in Time to First Byte (TTFB), and if your LCP element depends on a resource loaded after the HTML arrives, it cascades into a worse Largest Contentful Paint (LCP) too.
Cached subresources are also unavailable. A visitor who clicked through from Google has no cached copy of your fonts, hero image, or critical CSS. A visitor who just came from your homepage likely has all of those.
Same-origin navigations and the back-forward cache
Same-origin navigations open the door to two performance advantages that cross-origin navigations cannot use as reliably.
First, the Speculation Rules API lets you prefetch or prerender internal pages before the user clicks. The browser can have the next page fully rendered in a background tab, making the navigation instant. This only applies to same-origin destinations.
Second, the back-forward cache (bfcache) restores a page from memory when the user presses the back button. Bfcache hits are extremely fast and score well across all Core Web Vitals. They appear in your data as same-origin navigations. If your same-origin LCP is significantly better than your cross-origin LCP, bfcache and prefetch are likely contributing to that gap.
How to read this dimension in CoreDash

In CoreDash, use Navigation Origin as a filter or as a breakdown dimension alongside any metric. The most useful comparison is LCP by navigation origin. A large gap between same-origin and cross-origin LCP tells you one of three things:
- Your cross-origin entry pages have a slow TTFB that inflates LCP.
- Same-origin navigations benefit from prefetch or bfcache and your cross-origin pages do not.
- Your cached subresources help returning visitors but not first-time arrivals from external sources.
Cross-origin data is typically the more important number for SEO. Google's Chrome UX Report (CrUX) includes all navigation types, but organic search traffic is almost entirely cross-origin. If your cross-origin LCP passes while your same-origin LCP fails, that is unusual and worth investigating. The reverse is far more common.
Reducing the cross-origin penalty
You cannot eliminate the cold-start penalty entirely, but you can reduce it:
- Use a CDN with a fast TTFB. Connection overhead shrinks when your server is geographically close to the user and responds quickly. Target a TTFB below 200 ms for the HTML document.
- Preload the LCP image. A
<link rel="preload">in the<head>starts the image fetch as early as possible, cutting the time between HTML delivery and LCP element paint. - Inline critical CSS. No render-blocking stylesheet request means the browser can paint sooner even on a cold connection.
- Add
preconnecthints for third-party origins. If your LCP image or a render-blocking resource is hosted on a different domain, arel="preconnect"hint starts the TCP and TLS work early.
For same-origin navigations, the Speculation Rules API is the highest-impact improvement available today. Prerendering the most likely next page cuts LCP to near zero for those transitions.
Navigation Origin in context
Navigation Origin works well alongside the Navigation Type dimension (which separates navigate, reload, back-forward, and prerender) and the Effective Connection Type dimension. A cross-origin navigation on a slow connection is the hardest scenario your site faces. Filtering to those two conditions together will show you your true worst-case performance and where the biggest improvements are available.