Core/Dash 维度： 导航类型

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

免费试用

Trusted by market leaders · Client results

ebaynestlehappyhorizonmy work featured on web.devaleteiasnvperioncomparekpnadevintasaturnerasmusmcworkivawhowhatwearfotocasanina careloopearplugsvpnharvardmarktplaatsdpg mediamonarch

维度：导航类型 (nt)

您的 CrUX 数据中的每个页面浏览量都带有一个导航类型 (navigation type)。它告诉您浏览器是如何加载该页面的，这决定了涉及哪些浏览器系统：网络堆栈、往返缓存 (back/forward cache)、预渲染 (prerender) 管道或会话恢复。CoreDash 将其公开为 nt 维度，以便您可以分别过滤和比较每个导航上下文中的 Core Web Vitals。

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

为什么导航类型很重要

跨所有导航类型汇总 LCP 或 INP 会产生一个在技术上正确但在实践中具有误导性的数字。往返缓存 (bfcache) 命中在几毫秒内即可完成。冷导航 (cold navigate) 则需要等待 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% 的会话是 reload。

back_forward

用户按下了浏览器的后退或前进按钮。如果 往返缓存 (back/forward cache) (bfcache) 正常工作，这是最快的导航类型。浏览器直接从内存中恢复页面，根本没有任何网络请求。bfcache 命中的 LCP 实际上是从内存中绘制的时间，几乎是瞬间的。

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

prerender

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

如果您的 prerender LCP 看起来很正常，则发生了以下三种情况之一：预渲染在激活前被丢弃，推测规则定位了错误的 URL，或者页面使用了阻止预渲染的标头或 JavaScript。大约 3% 的 CoreDash 会话是预渲染激活，但一旦部署了 Speculation Rules，该比例就会迅速上升。

restore

标签页在浏览器关闭或标签页崩溃后被恢复。浏览器从头开始重新加载页面，但会话被视为恢复 (restore) 而不是全新的导航。性能类似于冷导航。这约占会话的 2%，很少成为优化工作的重点，但如果您的用户所在的浏览器会话不稳定，则值得进行监控。

调试工作流

  1. 将 navigate LCP 与您的整体 LCP 目标进行比较。 这是您全新加载性能的基准数据。如果 navigate 已经达标，那么您的问题出在其他地方。
  2. 对照 navigate 检查 back_forward。 如果它们很接近，说明 bfcache 损坏。打开 Chrome DevTools，转到 Application 面板，并运行 bfcache 测试。DevTools 的输出会准确列出哪些功能或标头阻碍了 bfcache 的资格。
  3. 检查 prerender LCP。 如果它高于 200 毫秒，则预渲染管道未能正常交付。验证您的 Speculation Rules JSON 是否有效，检查目标页面是否没有返回阻塞逻辑，并确认 Chrome DevTools 中 Speculation Rules 下是否在计算激活次数。

工程经验法则

  • navigate: 应该通过常规优化满足您的 LCP 阈值：快速的 TTFB，在 LCP 图像上使用 fetchpriority="high"，没有渲染阻塞资源。
  • back_forward: 应该比 navigate 快 10 到 20 倍。如果不是，说明 bfcache 损坏。
  • prerender: 应该显示低于 200 毫秒的 LCP。如果不是，则您的 Speculation Rules 配置有误。
  • reload: TTFB 不应该比 navigate 差太多。如果是这样，请修复您的缓存重新验证标头。

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