Core/Dash 维度： Navigation Type

维度：Navigation Type (nt)

你的 CrUX 数据中的每一次页面访问都包含一个导航类型。它会告诉你浏览器是如何加载页面的，从而决定了涉及哪些浏览器系统：网络栈、往返缓存、预渲染管道或会话恢复。CoreDash 将其作为 nt 维度公开，以便你能够分别过滤和对比每个导航上下文中的 Core Web Vitals。

该数据来自 PerformanceNavigationTiming API，具体是 type 属性。你可以通过 performance.getEntriesByType("navigation")[0].type 来读取它。Chrome 会在向 CrUX 发送的每个 web vitals 测量值中附带报告该值，而 CoreDash 会对其进行存储和索引，因此你无需编写任何自定义检测代码即可进行细分。

为什么 Navigation Type 很重要

将所有导航类型的 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% 的会话是 reload。

back_forward

用户点击了浏览器的后退或前进按钮。如果 往返缓存（bfcache）正常工作，这将是速度最快的导航类型。浏览器会直接从内存中恢复页面，完全不需要发送网络请求。bfcache 命中的 LCP 实际上就是从内存中绘制页面的时间，这几乎是瞬间完成的。

back_forward

如果你的 back_forward 指标与 navigate 相似，说明 bfcache 没有生效。最常见的原因包括 unload 事件监听器、Cache-Control: no-store 响应头，以及在导航发生前未关闭的 IndexedDB 连接。CoreDash 数据显示，往返会话约占总会话数的 20%，这让它成为一个回报极高的优化点。

prerender

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

prerender

如果你的 prerender LCP 看起来与常规加载无异，通常是因为以下三种情况之一：预渲染在激活前被丢弃了、speculation rule 指向了错误的 URL，或者页面使用了阻止预渲染的响应头或 JavaScript。在 CoreDash 会话中，预渲染激活大约占 3%，但一旦部署了 Speculation Rules，这个比例就会迅速上升。

restore

在浏览器关闭或标签页崩溃后，标签页被恢复。浏览器会从头开始重新加载页面，但该会话被视为 restore，而不是全新的 navigate。其性能与冷导航类似。这大约占会话总数的 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：应该显示 200ms 以下的 LCP。否则，说明你的 Speculation Rules 配置有误。
• reload：TTFB 不应该显著差于 navigate。如果确实如此，请修复你的缓存重新验证响应头。

Navigation Type 是用于区分“我的页面性能如何？”与“在每种浏览器加载策略下，我的页面性能如何？”的维度。这种区分正是凭空猜测与真正调试的本质区别。