Core/Dash 维度： 导航类型

按用户到达页面的方式细分你的 Core Web Vitals，从而调试 bfcache、预渲染和重新加载的性能。

免费试用

Trusted by market leaders · Client results

ebaymy work featured on web.devsaturnnina careperionsnvworkivawhowhatwearadevintaloopearplugshappyhorizonaleteiamonarchnestledpg mediacomparefotocasamarktplaatsharvardvpnerasmusmckpn

维度：导航类型 (nt)

你的 CrUX 数据中的每次页面浏览都带有一个导航类型。它告诉你浏览器是如何加载页面的，这决定了涉及哪些浏览器系统：网络栈、后退/前进缓存、预渲染管道或会话恢复。CoreDash 将其暴露为 nt 维度，让你可以在不同的导航上下文中分别过滤和对比 Core Web Vitals。

这些数据来自 PerformanceNavigationTiming API，具体来说是 type 属性。你可以通过 performance.getEntriesByType("navigation")[0].type 来读取它。Chrome 在向 CrUX 发送每一项 web vitals 测量数据时都会附带这个值，CoreDash 对其进行存储和索引，因此你无需编写任何自定义埋点即可进行细分。

coredash metric table urls

为什么导航类型很重要

将所有导航类型的 LCP 或 INP 汇总在一起，得出的数字在技术上是正确的，但在实际中却极具误导性。后退/前进缓存命中在几毫秒内即可完成。冷导航则需要等待 DNS、TCP、TLS 和 TTFB。如果你的会话中有 20% 是 bfcache 命中，它们会拉低你的 p75 LCP，让你更难发现全新导航中存在的真正问题。

反之亦然。如果你网站上的 bfcache 已损坏，后退/前进会话的性能将和全新导航一样差。如果不按导航类型进行细分，你永远不会注意到这一点，因为汇总数据依然保持稳定。

预渲染是最极端的情况。正确预渲染的页面 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) 正常工作，这是可能的最快导航类型。浏览器从内存中恢复页面，完全没有任何网络请求。bfcache 命中的 LCP 实际上是从内存中绘制的时间，这几乎是瞬间完成的。

如果你的 back_forward 指标看起来与 navigate 相似，说明 bfcache 没有正常工作。最常见的原因是 unload 事件处理程序、Cache-Control: no-store 响应头，以及在导航前未关闭的开放 IndexedDB 连接。CoreDash 数据显示后退/前进约占会话的 20%，这让修复它成为一项高回报的优化。

prerender

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

如果你的 prerender LCP 看起来很普通，那是发生了以下三种情况之一：预渲染在激活前被丢弃、Speculation Rules 指向了错误的 URL，或者页面使用了阻止预渲染的请求头或 JavaScript。大约 3% 的 CoreDash 会话是预渲染激活，但一旦部署了 Speculation Rules，这个比例就会迅速上升。

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"，且没有 render blocking 资源。
  • back_forward：应该比 navigate 快 10 到 20 倍。如果不是，说明 bfcache 已损坏。
  • prerender：LCP 应该在 200ms 以下。如果不是，说明你的 Speculation Rules 配置有误。
  • reload：TTFB 不应该比 navigate 差太多。如果是，请修复你的缓存重新验证响应头。

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