Core/Dash 维度： 导航来源

查看您的访问者是来自相同域名还是外部来源，以及这种划分如何影响您的 Core Web Vitals。

免费试用

Trusted by market leaders · Client results

whowhatwearkpnsaturnworkivaerasmusmchappyhorizonfotocasamy work featured on web.devharvardloopearplugsmarktplaatsvpnaleteiacomparemonarchsnvadevintanestleebayperionnina caredpg media

导航来源衡量什么

导航来源维度将您的现场数据分为两组：

  • 同源 (Same Origin) (1) — 上一个页面位于同一域名下。
  • 跨源 (Cross Origin) (2) — 用户来自不同的域名、搜索引擎、社交平台，或者直接输入了 URL。

这种区分很重要，因为这两种情况下浏览器的起始条件完全不同。同源导航可以重用现有连接，利用 HTTP 缓存获取子资源，并从您网站设置的任何预获取（prefetching）中受益。而跨源导航则一切从零开始。

为什么跨源导航更慢

当用户点击外部网站上的链接时，浏览器在请求您的 HTML 之前还需要做一些工作：

  1. DNS 查找 — 将您的域名解析为 IP 地址。
  2. TCP 握手 — 建立与您的服务器的连接。
  3. TLS 协商 — 完成 HTTPS 握手。

在请求页面的第一个字节之前，这些步骤通常会在移动连接上增加 200 到 500 毫秒的延迟。这一成本直接反映在 Time to First Byte (TTFB) 中，并且如果您的 LCP 元素依赖于 HTML 到达后加载的资源，它也会连锁反应导致更差的 Largest Contentful Paint (LCP)。

缓存的子资源也不可用。从 Google 点击进入的访问者没有您的字体、首图或关键 CSS 的缓存副本。而刚从您的主页过来的访问者很可能已经拥有了所有这些资源。

同源导航与往返缓存 (bfcache)

同源导航开启了两个性能优势的大门，而跨源导航则无法如此可靠地利用它们。

首先，推测规则 API (Speculation Rules API) 允许您在用户点击之前预获取 (prefetch) 或预渲染 (prerender) 内部页面。浏览器可以在后台标签页中将下一个页面完全渲染出来，从而实现瞬间导航。这仅适用于同源目标。

其次，当用户按下后退按钮时，往返缓存 (back-forward cache, bfcache) 会从内存中恢复页面。命中 bfcache 速度极快，并且在所有 Core Web Vitals 指标上表现优异。它们在您的数据中显示为同源导航。如果您的同源 LCP 明显优于跨源 LCP，那么 bfcache 和 prefetch 很有可能是造成这种差距的原因。

如何在 CoreDash 中解读此维度

coredash metric table urls

在 CoreDash 中，可以将导航来源作为过滤器，或作为与任何指标并列的细分维度。最有用的对比是按导航来源划分的 LCP。同源 LCP 和跨源 LCP 之间的巨大差距说明了以下三点之一：

  • 您的跨源入口页面 TTFB 较慢，从而拖慢了 LCP。
  • 同源导航受益于 prefetch 或 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 握手工作。

对于同源导航，推测规则 API (Speculation Rules API) 是目前能带来最大影响的改进方案。预渲染最有可能的下一个页面能将这些过渡的 LCP 降至接近零。

将导航来源结合上下文

导航来源维度与 导航类型 (Navigation Type) 维度（区分 navigate、reload、back-forward 和 prerender）以及 有效连接类型 (Effective Connection Type) 维度结合使用效果极佳。在慢速连接上进行跨源导航是您的网站面临的最严峻场景。同时过滤这两个条件将向您展示真实的“最差情况”性能，以及最大的改进空间所在。