CoreDash 维度： 导航类型

根据用户到达页面的方式对您的 Core Web Vitals 进行细分，以调试 bfcache、prerender 和 reload 的性能。

免费试用

Trusted by market leaders · Client results

dpg mediamonarchnestlemarktplaatsloopearplugsmy work featured on web.devvpnwhowhatwearhappyhorizoncomparealeteiafotocasaerasmusmcsnvebayworkivaadevintakpnsaturnharvardnina careperion

维度：导航类型 (nt)

CrUX 数据中的每一次页面访问都带有一个导航类型。它会告诉您浏览器是如何加载页面的，这决定了涉及哪些浏览器系统：网络栈、bfcache、prerender 流水线或会话恢复。CoreDash 将其公开为 nt 维度，以便您可以分别过滤和比较每个导航上下文中的 Core Web Vitals。

数据来自 PerformanceNavigationTiming API，特别是 type 属性。您可以使用 performance.getEntriesByType("navigation")[0].type 来读取它。Chrome 会在发送给 CrUX 的每次 web vitals 测量中报告此值，CoreDash 会对其进行存储和索引，因此您无需编写任何自定义埋点即可进行细分。

coredash metric table urls

为什么导航类型很重要

聚合所有导航类型的 LCP 或 INP 会产生一个技术上正确但在实践中具有误导性的数字。bfcache 命中可在几毫秒内完成。而冷启动导航则需要等待 DNS、TCP、TLS 和 TTFB。如果您的会话中有 20% 是 bfcache 命中，它们会拉低您的 p75 LCP，使新鲜导航上的真实问题变得难以察觉。

反之亦然。如果您的网站上的 bfcache 已损坏，则回退/前进会话的性能将与新鲜导航一样糟糕。如果不按导航类型细分，您将永远不会注意到这一点，因为聚合数据保持稳定。

Prerender 是最引人注目的案例。一个正确预渲染的页面应该显示接近于零的 LCP，因为在用户点击链接之前渲染就已经完成了。如果您的预渲染页面显示正常的 LCP 数字，则说明 Speculation Rules 配置有误，预渲染要么没有触发，要么在被使用前就被丢弃了。

导航类型

navigate

标准导航：用户输入了 URL、点击了来自另一个网站的链接或跟随了重定向。这是一次完整的页面加载，没有缓存快捷方式。浏览器会经历完整的请求流水线，包括 DNS 查询、连接建立和完整的资源加载。在 CoreDash 数据中，navigate 约占会话的 65%。这是您的基准。所有其他导航类型都应根据它们与 navigate 的比较情况来判断。

reload

用户按了 F5、点击了浏览器的刷新按钮，或者您的代码调用了 location.reload()。浏览器会为缓存资源发送重新验证请求，这意味着尽管用户在同一个页面上，但 TTFB 通常看起来比 navigate 更糟。如果您的 reload TTFB 显著高于 navigate TTFB，说明您的缓存标头在每次刷新时都会触发重新验证，而不是提供过期内容。在典型的 CoreDash 流量中，大约 10% 的会话是刷新。

back_forward

用户点击了浏览器的后退或前进按钮。如果 bfcache (back/forward cache) 正在运行，这是最快的导航类型。浏览器直接从内存中恢复页面，完全没有网络请求。bfcache 命中的 LCP 实际上是从内存绘制的时间，几乎是瞬时的。

如果您的 back_forward 指标看起来与 navigate 相似，说明 bfcache 未生效。最常见的原因是 unload 事件处理程序、Cache-Control: no-store 响应标头，以及在导航前未关闭的开启状态的 IndexedDB 连接。CoreDash 数据显示 back_forward 约占会话的 20%，这使其成为一个高杠杆的修复项。

prerender

在用户点击链接之前，页面已使用 Speculation Rules API 在后台加载。当用户确实点击时，预渲染的文档会立即激活。正确激活的预渲染页面的 LCP 接近于零，因为所有渲染工作都在导航事件之前完成了。

如果您的 prerender LCP 看起来正常（而非接近零），则发生了以下三件事之一：预渲染在激活前被丢弃了、猜测规则（speculation rule）针对了错误的 URL，或者页面使用的标头或 JavaScript 阻止了预渲染。大约 3% 的 CoreDash 会话是预渲染激活，但一旦部署了 Speculation Rules，该比例会迅速上升。

restore

浏览器关闭后标签页被恢复，或者标签页崩溃后被恢复。浏览器从头开始重新加载页面，但会话被视为恢复（restore）而非新鲜导航。其性能与冷启动导航相似。这约占会话的 2%，很少是优化工作的重点，但如果您有处于不稳定浏览器会话中的用户，则值得监控。

调试工作流程

  1. 将 navigate LCP 与您的整体 LCP 目标进行比较。 这是您新鲜加载性能的真实基准。如果 navigate 已经达标，那么您的问题出在别处。
  2. 检查 back_forward 与 navigate 的对比。 如果它们很接近，说明 bfcache 坏了。打开 Chrome DevTools，进入 Application 面板，运行 bfcache 测试。DevTools 的输出将准确列出哪些功能或标头正在阻止 bfcache 资格。
  3. 检查 prerender LCP。 如果高于 200ms，说明预渲染流水线没有生效。验证您的 Speculation Rules JSON 是否有效，检查目标页面是否返回了阻止逻辑，并确认 Chrome DevTools 的 Speculation Rules 下是否记录了激活。

工程师经验法则

  • navigate： 应通过常规优化达到您的 LCP 阈值：快速的 TTFB、LCP 图像上的 fetchpriority="high"、无阻塞渲染资源。
  • back_forward： 应比 navigate 快 10 到 20 倍。如果不是，说明 bfcache 坏了。
  • prerender： 应显示 LCP 低于 200ms。如果不是，说明您的 Speculation Rules 配置有误。
  • reload： TTFB 不应比 navigate 显著变差。如果是，请修复您的缓存重新验证标头。

导航类型是将“我的页面表现如何？”与“在每种浏览器加载策略下我的页面表现如何？”区分开来的维度。这种区分就是瞎猜与调试之间的区别。