从 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">我们建议网站实现自己的真实用户监控 (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
指标绘制为堆叠条形:
![堆叠条形图,显示过去 3 周的导航类型历史记录,其中大部分导航都是“导航”而且在三周内没有重大变化。](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/navigation-types-history-chart.png?authuser=9&hl=el)
在前面的屏幕截图中,历史记录仅提供 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)。
![显示即时网页加载所占比例与 bfcache 网页加载比例之间存在紧密关联的相关性图表](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/instant-lcp-bfcache-correlation.png?authuser=9&hl=el)
大家对用于此次分析的 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">![CrUX 信息中心内“Navigation Types Distribution”屏幕的屏幕截图,其中显示了一个月的数据。](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/crux-dashboard-navigation-types.png?authuser=9&hl=el)
您同样可以看到,我们在信息中心的此页面的顶部突出显示了更快的导航类型,您应对这些类型进行优化。
总结
我们希望 CrUX 中的导航类型细分对您有所帮助,并有助于您了解和优化网站的性能。通过确保高效使用 HTTP 缓存、bfcache 和预渲染,网站可以比需要返回到服务器的网页加载速度快得多。
我们也很高兴在所有不同的 CrUX 接入点上提供数据,以便用户根据需要使用数据,并查看 CrUX API 中显示的数据的类型细分(按网址)。