Trusted by market leaders · Client results
导航来源的测量指标
导航来源维度将您的现场数据分为两组：
- 同源 (Same Origin) (1) — 上一个页面位于同一域名。
- 跨源 (Cross Origin) (2) — 用户来自不同的域名、搜索引擎、社交平台，或直接输入了 URL。
这种区别非常重要，因为在每种情况下浏览器的起始条件完全不同。同源导航可以重用现有的连接，利用 HTTP 缓存获取子资源，并从您网站设置的任何预获取中受益。而跨源导航则一切从头开始。
为什么跨源导航速度较慢
当用户点击外部网站的链接时，在能够请求您的 HTML 之前，浏览器需要完成以下工作：
- DNS 查找 — 将您的域名解析为 IP 地址。
- TCP 握手 — 打开与您的服务器的连接。
- TLS 协商 — 完成 HTTPS 握手。
在移动网络连接上，在请求页面的第一个字节之前，这些步骤通常会增加 200 到 500 毫秒的时间。这种延迟会直接体现在 Time to First Byte (TTFB) 中，并且如果您的 LCP 元素依赖于 HTML 到达后加载的资源，它还会连锁导致更差的 Largest Contentful Paint (LCP)。
缓存的子资源同样不可用。从 Google 点击进入的访客没有您的字体、首图或关键 CSS 的缓存副本。而刚刚从您主页过来的访客则很可能拥有所有这些缓存。
同源导航与往返缓存（back-forward cache）
同源导航开启了两种跨源导航无法可靠使用的性能优势。
首先，Speculation Rules API 允许您在用户点击之前预获取或预渲染内部页面。浏览器可以在后台标签页中将下一个页面完全渲染好，从而实现即时导航。这仅适用于同源目标。
其次，当用户按下后退按钮时，往返缓存（bfcache） 会从内存中恢复页面。bfcache 命中速度极快，在所有 Core Web Vitals 中得分都很高。在您的数据中，它们显示为同源导航。如果您的同源 LCP 明显优于跨源 LCP，则很可能是 bfcache 和预获取促成了这种差距。
如何在 CoreDash 中解读此维度
在 CoreDash 中，您可以将导航来源用作过滤器，或作为任何指标旁边的细分维度。最有用的对比是按导航来源划分的 LCP。同源 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 维度（区分导航、重载、往返和预渲染）以及 Effective Connection Type 维度配合使用效果极佳。缓慢连接上的跨源导航是您的网站面临的最严峻场景。将这两个条件组合进行过滤，将向您展示真实的最差性能情况，并指出潜在的最大改进空间。