CrUX 中现已提供导航类型

Barry Pollard

Johannes Henkel

从 2024 年 3 月的数据集开始，Chrome 用户体验报告 (CrUX) 中添加了 navigation_types 指标。这些数据会针对查询的维度提供网页加载导航类型的汇总统计信息。

不同的导航类型会导致效果指标存在差异，因此在了解您网站的表现时，了解这些不同导航类型的相对频率非常有用。例如，当导航使用后退 (bfcache) 时，通常会导致导航近乎即时，这反映在非常小的 LCP 和 FCP 指标中，并且 CLS 和 INP 指标也有所降低。

通过公开导航类型细分，我们希望能够鼓励网站所有者更加了解其网站上使用的导航类型，并通过查看缓存设置、bfcache 拦截器和预呈现来鼓励一些更快的导航类型。

navigation_types 指标可在每日 CrUX API、CrUX History API（最初提供 3 周历史记录，并在接下来的 6 个月内每周增加到全面覆盖）、最新的 CrUX BigQuery 数据集和 CrUX 信息中心。拥有历史记录还可以让网站所有者查看导航类型使用情况随时间的变化。这样可以跟踪改进情况（例如，消除 bfcache 阻塞）。它还可以帮助解释指标变化，即使网站没有发生任何变化。

CrUX 中提供哪些导航类型？

CrUX 对下表中的以下导航类型进行了区分：

类型	说明
navigate	网页加载，不属于任何其他类别。
navigate_cache	从 HTTP 缓存提供主要资源（主 HTML 文档）的网页加载。网站通常会将缓存用于子资源，但主 HTML 文档的缓存量通常要少得多。如果可以，则能够在本地和 CDN 进行缓存可以显著提升性能。
reload	用户通过以下方式重新加载了页面：点击重新加载按钮、在地址栏中按 Enter 键，或撤消标签页关闭操作。网页重新加载通常会导致重新验证回服务器，以检查主页面是否已更改。较高的网页重新加载百分比可能表明用户对此感到失望。
restore	该网页在浏览器重启后重新加载，或者某个标签页因内存原因而被移除。对于 Android 版 Chrome，这些错误会报告为 reload。
back_forward	历史记录导航，表示最近查看过网页并返回了该网页。正确缓存应该能带来相当快的体验，但仍然需要处理网页和执行 JavaScript，而 bfcache 都可以避免这两种情况。
back_forward_cache	从 bfcache 提供的历史记录导航。优化网页以利用 bfcache 应该带来更快的体验。网站应设法移除 bfcache 障碍，以提高此类导航的比例。
prerender	网页是预渲染的，这与 bfcache 类似，可以近乎即时地完成网页加载。

在某些情况下，网页加载可能是多种导航类型的组合。在这种情况下，CrUX 会按照上表的反向顺序（从下到上）报告第一个匹配项。

CrUX 中导航类型的限制

由于 CrUX 是公共数据集，因此其报告粒度受到限制。对于许多源和网址，由于符合条件的流量不足，因此 navigation_types 指标不可用。如需了解详情，请参阅 CrUX 方法。

此外，CrUX 无法按导航类型提供其他指标的细分数据，因为这会进一步减少 CrUX 中提供的来源和网址的数量。

<ph type="x-smartling-placeholder">

</ph> 重要提示：导航类型不是 CrUX 中的维度，无法按导航类型查询 LCP 等性能指标。它们只是根据现有维度进行的一部分细分。

我们建议网站实现自己的真实用户监控 (RUM)，以便能够按照导航类型等条件来划分流量。请注意，这些解决方案中的导航类型可能会因报告的类型以及包含的网页浏览量而异。请参阅“为什么 CrUX 数据与我的 RUM 数据不同？”一文。

RUM 还可以提供有关特定性能问题的更多详细信息。例如，虽然 CrUX 可能意味着提升 bfcache 资格是值得的，但 bfcache notRestoredReasons API 可以确切说明无法通过 bfcache 提供特定网页加载的原因。

CrUX API 中的导航类型

如需查看 API 中的导航类型，请在请求中添加 navigation_types 指标，或者不要设置指标来包含所有指标：

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

API 文档中更详细地介绍了请求格式，其中包括有关如何获取 API 密钥的说明和 API 指南。这将返回一个对象，如下所示：

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

在响应中，CrUX 会将 navigation_types 指标报告为一个对象，其中包含每种导航类型的网页加载比例。对于指定键，每个分数都是介于 0.0（表示 0% 的网页加载）到 1.0（表示 100% 的网页加载）之间的值。

从此响应中您可以看出，在 2024 年 3 月 6 日（含 2024 年 4 月 2 日及之前）的收集期内，有 6.77% 的导航（网页加载）是通过浏览器的 bfcache 提供的。同样，其他一些分数也有助于确定网页加载优化机会。请注意，对于任何给定键（包括网址或来源与设备规格的组合），navigation_types 分数相加之和约为 1.0。

CrUX History API 中的导航类型

CrUX History API 可以为导航类型提供时间序列，每个部分最多包含 25 个数据点，从而可以直观呈现这些部分随时间变化的情况。如需将请求从 CrUX API 更改为 CrUX History API，请针对 queryHistoryRecord 端点（而不是 queryRecord）运行该请求。例如，我们的 CrUX History Colab 将 navigation_types 指标绘制为堆叠条形：

<ph type="x-smartling-placeholder">

</ph>

不同时间段的导航类型

在前面的屏幕截图中，历史记录仅提供 3 个收集期（每个收集期 28 天，相隔 7 天）。填充完毕后，此字段将涵盖全部 25 个收集期。通过直观呈现此历史记录，您可以确认优化是否已生效或已经退化。对于 HTTP 缓存配置（针对 bfcache 和预渲染优化网页）来说尤其如此。

CrUX BigQuery 中的导航类型

CrUX BigQuery 表现在包含一条由每种类型组成的 navigation_type 记录，而具体化摘要视图包含多个 navigation_types_* 列，每个列对应一种类型。

详细表格

CrUX BigQuery 中详细表架构提供了网页性能指标的详细直方图，使我们能够在此示例分析中展示特定导航类型如何与即时或良好的加载性能相关联。

例如，我们考察了 back_forward_cache 比例及其与页面即时加载频率（instant_lcp_density 定义为 LCP <= 200 毫秒）和良好 LCP 出现的频率（good_lcp_density 定义为 LCP <= 2500 毫秒）的相关性。我们观察到back_forward_cache和instant_lcp_density之间存在很强的统计关联性 (r=0.87)（如下图所示），而back_forward_cache和good_lcp_density之间则有中等相关性 (r=0.29)。

<ph type="x-smartling-placeholder">

</ph>

即时网页加载与 bfcache 使用量的相关性

大家对用于此次分析的 Colab 给出了充分的肯定；在这里，我们仅讨论从 CrUX BigQuery 中的详细表中提取 1 万个最热门出发地的 navigation_types 分数的查询：

• 我们在此处访问 all.202403 表（请参阅 FROM 子句），并使用 phone 过滤 form_factor，并为排名前 10,000 的最热门的出发地选择热门程度排名 <= 10,000 的出发地（请参阅 WHERE 子句）。
• 在 BigQuery 中查询 navigation_types 指标时，需要除以 navigation_types 比例的总和，因为它们仅按源站相加，而不会按（源站、设备规格）组合相加。
• 并非所有源都有 navigation_types，因此最好使用 SAVE_DIVIDE。

WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

具体化表

当摘要足以满足需求时，查询具体化表通常更方便（也更便宜）。例如，以下查询从 chrome-ux-report.materialized.device_summary 表中提取可用的 navigation_types 数据。此表格按月份、来源和设备类型进行键控。

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

请注意，每行的分数加起来不等于 1.0，因此需要用每个分数除以要解释该查询的结果的总和。

原因在于，chrome-ux-report.materialized.device_summary 中的 navigation_type 比例（例如直方图密度）相加后，每个来源（而不是每个日期、每个来源和设备）加起来分别是 1.0。这样，您就可以查看跨设备的导航类型分布情况：

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

device	navigation_types_back_forward
phone	0.0663
desktop	0.0179
tablet	0.0009

在此查询结果中，这些比例反映了原始网页 https://www.google.com 的网页加载次数所占的百分比：6.63% 的网页加载在手机上属于 back_forward 导航类型，1.79% 在桌面设备上，在平板电脑上为 0.09%。

phone 上的 back_forward 百分比相当高，这表明我们可以尝试优化这些网页加载，以便通过 bfcache 提供它们。

但是，也请务必考虑 bfcache 已经处理了网页的加载比例，也就是 bfcache 命中率。以下查询表明，鉴于此特定来源的 >手机和桌面设备上的命中率为 60%。

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

device	back_forward_cache_hit_rate
phone	0.6239
desktop	0.6805
tablet	0.7353

因此，看起来手机上的高 back_forward 率并非因为 bfcache 使用量减少，而更多地反映了用户在手机上的往返导航频率较高。

CrUX 信息中心内的导航类型

如需查看导航类型，最简单的方法是在 CrUX 信息中心查看，可以通过此链接访问来源。如以下屏幕截图所示，最初只能提供一个月的数据，但随着时间的推移，历史记录会逐渐填满，让您能够看到每个月的类型变化。

<ph type="x-smartling-placeholder">

</ph>

CrUX 信息中心内的导航类型

您同样可以看到，我们在信息中心的此页面的顶部突出显示了更快的导航类型，您应对这些类型进行优化。

总结

我们希望 CrUX 中的导航类型细分对您有所帮助，并有助于您了解和优化网站的性能。通过确保高效使用 HTTP 缓存、bfcache 和预渲染，网站可以比需要返回到服务器的网页加载速度快得多。

我们也很高兴在所有不同的 CrUX 接入点上提供数据，以便用户根据需要使用数据，并查看 CrUX API 中显示的数据的类型细分（按网址）。

我们非常期待在社交媒体或 CrUX 论坛中就向 CrUX 添加内容的行为提供反馈。