从 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 中提供的来源和网址的数量。
我们建议网站实施自己的真实用户监控 (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 周内导航类型的历史记录的堆叠条形图,其中大部分导航为“导航”类型,在这 3 周没有重大更改。](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/navigation-types-history-chart.png?authuser=8&hl=lv)
在前面的屏幕截图中,历史记录只能提供 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
之间存在很强的统计相关性 (p=0.87)(如下图所示),而 back_forward_cache
和 good_lcp_density
之间也存在中等相关 (drawable=0.29)。
![显示即时网页加载比例与 bfcache 网页加载比例之间的强关联关系图](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/instant-lcp-bfcache-correlation.png?authuser=8&hl=lv)
用于此分析的 Colab 获得了很好的评论;在这里,我们只讨论了从 CrUX BigQuery 的详细表格中提取 1 万个最热门出发地的 navigation_types 比例的查询:
- 我们在此处访问
all.202403
表(请参阅FROM
子句),然后过滤出phone
的form_factor
,并选择热门程度排名 <= 10000 的前 1 万个最热门源(请参阅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 信息中心内查看,可通过此链接访问某个源站。从以下屏幕截图中可以看出,最初只提供了一个月的数据,但随着时间的推移,历史记录将会不断填满,让您可以逐月查看类型的变化。
![CrUX 信息中心内“Navigation Types Distribution”屏幕的屏幕截图,其中显示了一个月的数据。](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/crux-dashboard-navigation-types.png?authuser=8&hl=lv)
如您所见,我们在信息中心的这个页面的顶部突出显示了速度较快的导航类型,各位应力求进行优化。
总结
我们希望 CrUX 中的导航类型细分功能对您有用,并且可以帮助您了解和优化网站的性能。通过确保有效利用 HTTP 缓存、bfcache 和预渲染,网站可以比需要往返服务器的网页加载速度更快。
我们还很高兴在所有 CrUX 接入点中提供数据,以便用户可以根据需要使用数据,并查看 CrUX API 中公开的网址的类型细分(按网址)。