Trusted by market leaders · Client results
导航来源衡量的指标
导航来源维度将您的真实用户数据分为两组：
- 同源 (Same Origin) (1) — 上一个页面位于同一域名。
- 跨源 (Cross Origin) (2) — 用户来自不同的域名、搜索引擎、社交平台，或直接输入了 URL。
这种区分非常重要，因为在这两种情况下，浏览器的初始条件截然不同。同源导航可以重用现有连接，利用 HTTP 缓存获取子资源，并受益于您站点设置的任何预获取（prefetching）。而跨源导航则完全从零开始。
为什么跨源导航更慢
当用户点击外部网站的链接时，浏览器在请求您的 HTML 之前还需要做一些准备工作：
- DNS 查询 — 将您的域名解析为 IP 地址。
- TCP 握手 — 打开与您的服务器的连接。
- TLS 协商 — 完成 HTTPS 握手。
在移动网络连接下，这些步骤通常会在请求页面的第一个字节之前增加 200 到 500 毫秒的延迟。这种开销直接体现在 Time to First Byte (TTFB) 中，并且如果您的 LCP 元素依赖于 HTML 到达后加载的资源，它也会连锁反应导致更差的 Largest Contentful Paint (LCP)。
缓存的子资源也同样不可用。从 Google 点击进入的访客没有您的字体、首屏关键图像（hero image）或关键 CSS 的缓存副本。而刚刚从您主页过来的访客则很可能拥有所有这些缓存。
同源导航与往返缓存（bfcache）
同源导航开启了跨源导航无法可靠使用的两项性能优势的大门。
首先，Speculation Rules API 允许您在用户点击之前预获取（prefetch）或预渲染（prerender）内部页面。浏览器可以在后台标签页中将下一页完全渲染好，从而实现即时导航。这仅适用于同源目标。
其次，当用户按下后退按钮时，往返缓存（bfcache） 会从内存中恢复页面。命中 bfcache 的速度极快，并且在所有 Core Web Vitals 指标上得分都很高。它们在您的数据中显示为同源导航。如果您的同源 LCP 明显优于跨源 LCP，那么 bfcache 和预获取很可能是造成这一差距的原因。
如何在 CoreDash 中解读此维度
在 CoreDash 中，您可以将导航来源用作过滤器，或作为任何指标的细分维度。最实用的对比是按导航来源划分的 LCP。同源和跨源 LCP 之间的巨大差距说明了以下三种情况之一：
- 您的跨源入口页面 TTFB 较慢，从而推高了 LCP。
- 同源导航受益于预获取或 bfcache，而您的跨源页面则没有。
- 您的缓存子资源有助于回访者，但对来自外部来源的首次访客没有帮助。
对于 SEO 而言，跨源数据通常是更重要的数据。Google 的 Chrome UX Report (CrUX) 包含所有导航类型，但自然搜索流量几乎全部是跨源的。如果您的跨源 LCP 合格而同源 LCP 不合格，这是很不寻常的，值得深入调查。反之则常见得多。
减少跨源性能损失
您无法完全消除冷启动的性能损失，但可以将其降低：
- 使用具有快速 TTFB 的 CDN。 当您的服务器在地理位置上靠近用户并快速响应时，连接开销就会缩小。目标是将 HTML 文档的 TTFB 控制在 200 毫秒以下。
- 预加载 LCP 图像。 在
<head>中使用<link rel="preload">可以尽早开始图像获取，缩短 HTML 传输与 LCP 元素绘制之间的时间。 - 内联关键 CSS。 没有阻塞渲染的样式表请求意味着即使在冷启动连接上，浏览器也可以更早地进行绘制。
- 为第三方源添加
preconnect提示。 如果您的 LCP 图像或阻塞渲染的资源托管在不同的域名上，rel="preconnect"提示会提前启动 TCP 和 TLS 工作。
对于同源导航，Speculation Rules API 是目前影响力最大的改进方式。预渲染最有可能的下一个页面可以使这些过渡的 LCP 降至接近零。
结合上下文分析导航来源
导航来源与 导航类型 (Navigation Type) 维度（区分 navigate、reload、back-forward 和 prerender）以及 有效连接类型 (Effective Connection Type) 维度结合使用效果极佳。在慢速连接下的跨源导航是您的站点面临的最艰难的场景。同时过滤这两个条件将向您展示真实的最差性能情况，以及最大幅度的改进空间在哪里。