发布时间：2025 年 2 月 11 日
2025 年 2 月发布的 Chrome 用户体验报告 (CrUX) 包含许多令人兴奋的新指标（以及经过更改的指标）：
- Largest Contentful Paint (LCP) 图片子部分和资源类型
- 往返时间 (RTT) 详情
- 移除了“有效的连接类型”(ECT) 维度
这两种报告都能让您更深入地了解 CrUX 中提供的来源和网址的效果指标，本文将详细说明原因。
LCP 诊断信息
我们最初在 2022 年 Google I/O 大会上提出了 LCP 子部分的概念，这是一种有效的方法，可将包含图片 LCP 的网页的 LCP 用时细分为更小的组成部分，以确保您将精力用于优化导致 LCP 较高的问题的正确原因。
对该演讲中 HTTP Archive 实验室数据的分析表明，图片下载时间通常是 LCP 时间中最短的部分。许多实验室工具（包括 Google 自己的 Lighthouse）通常会提供有关优化图片格式和大小的建议，以缩短下载时间并提升性能。虽然该建议仍然正确，但分析结果表明，我们可能过于强调了该建议，更大的问题在于浏览器找到图片并开始下载之前出现的延迟。
虽然分析实验室数据很有用，但网站在现实生活中的使用方式往往会有所不同，因此能够查看实测数据的这些子部分至关重要。去年发布的一篇博文通过实地数据证实了有关如何优化 LCP 的常见误解。
LCP 图片子部分
在此次版本中，网站所有者可以在源或网址级别检查自己的网站是否存在图片 LCP 子部分。
子部分仅适用于图片，不包括第一帧视频图片（由于我们无法衡量完整的下载时间，因此这类图片稍微复杂一些）。文本子部分也不会纳入考量范围，因为它们的用处不大，并且会导致图片 LCP 数值失真。对于主要由文本 LCP 组成的网站，总体 TTFB 和总体 FCP 指标非常有用，但请注意，这些指标涵盖所有 LCP，而不仅仅是文本 LCP。最后，系统仅在完整网页加载时收集图片子部分，而 LCP 指标本身也会在返回导航和预渲染网页时收集。
自 2025 年 2 月起，这些数据已添加到 CrUX API 和 CrUX History API（请注意，不是 BigQuery）。CrUX History API 在发布时提供两周的数据，随着时间的推移，这些数据将会增加到完整的 25 周历史数据。这些 API 会以毫秒为单位提供每个子部分的 75 百分位数数据。
例如，如需获取 PHONE 网页浏览的 https://web.dev/ 的 LCP 图片子部分，您可以使用以下 curl 命令（将 API_KEY 替换为您自己的键）：
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
您会收到类似以下内容的回复：
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
我们更新了 CrUX Vis 工具，以包含这些数据，并且预计使用 CrUX API 的其他第三方工具也将会显示这些有价值的数据：
在本例中，我们可以看到，对于某个热门媒体网站，资源加载时长是影响最小的组成部分。此网站真正有改进空间的是 TTFB 和资源加载延迟，元素渲染延迟的改进空间较小。
每个子部分中的高值表示不同的问题：
- 首字节时间 (TTFB) 过高通常表示存在服务器、网络或重定向问题，如优化 TTFB 中所述。
- 资源加载延迟时间较长表示浏览器发现 LCP 图片的时间较晚，例如，由客户端 JavaScript 注入的 LCP 图片需要一段时间才能运行。
- 如果资源加载时长较长，您应考虑缩减图片下载大小。
- 元素呈现延迟时间过高是指图片可用（可能通过
<link rel=preload>提供，但很长时间未使用），这通常是由于显示图片需要使用客户端 JavaScript 所致。
我们希望通过在 CrUX 中提供来源级和网址级（需满足常规资格条件）的数据，帮助网站更轻松地优化其 LCP 指标。
LCP 资源类型
由于子部分最适合用于查看图片 LCP，因此 CrUX 仅将此类数据限制为包含图片的网页。因此，了解有多少 LCP 是图片 LCP，而不是文本 LCP（例如 <h1> 标题和长段落）非常重要。
除了 LCP 图片子部分之外，CrUX API 现在还包含资源细分，显示了文本和图片在 LCP 网页加载时间中的占比。
例如，如需获取 PHONE 网页浏览的 https://web.dev/ 的 LCP 资源类型，您可以使用以下 curl 命令（再次将 API_KEY 替换为您自己的键）：
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
您会收到类似以下内容的回复：
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX 可视化图表也已更新，可显示以下数据：
例如，对于 web.dev 的首页，我们可以看到 98.5% 的 LCP 实际上是文本 LCP，因此 LCP 图片子部分对此页面来说不太实用。在这种情况下，我们可以使用原始的 TTFB 和 FCP 指标作为可能更准确的诊断细分。
LCP 资源类型是另一种有用的诊断工具，可用于了解和改进 LCP，尤其是了解 LCP 图片子部分的实用性。
RTT 诊断信息
我们还扩展了于 2024 年 8 月首次引入的 RTT 指标。
RTT 三分箱
我们在 CrUX API 中添加了三分位计，用于显示三组 RTT 密度：
| 网络延迟 | 开始 | 结束 |
|---|---|---|
| 低 | 0 毫秒 | < 75 毫秒 |
| 中 | 75 毫秒 | < 275 毫秒 |
| 高 | 275 毫秒 | ∞ |
这些分桶比之前的 ECT 类别更具信息性，后者将所有小于 270 毫秒的请求都归入 4g 类别。自这些类别推出以来，网络技术不断进步，大多数网站的大部分流量都属于该类别，因此这种分类的用处不大。
因此，我们建议使用低、中和高分布标签，而不是常用的良好、有待改进和不佳标签。这些指标不是网站所有者可以直接改进的指标，因此是诊断指标，用于了解其他指标以及它们可能与预期不同的原因。它们还有助于解释其他指标随时间推移而发生变化的原因，即使网站没有变化，但如果指标显示用户群发生变化，也可能存在这种情况。
这些分桶在 CrUX API 中提供，例如，web.dev 用于 PHONE 网页浏览（再次将 API_KEY 替换为您自己的键）：
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
该命令会返回如下内容：
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
选择分布后，这些分桶会显示在 CrUX 可视化图表中：
BigQuery 中的 RTT
除了在 CrUX API 中扩展 RTT 指标以包含三分位数桶之外，我们还在每月 BigQuery 数据集中提供了这些数据，包括原始表中的 25 毫秒分桶的完整直方图，以及具体化表中的三分位数桶和 p75 值。
这样一来，您就可以更深入地了解 CrUX API 中提供的三分位数据桶之外的数据分布情况。这还让我们能够重新创建自本月起从 CrUX 中移除的 ECT 细分（稍后会详细介绍）- 只需对 4g 的阈值进行细微更改，将其从之前的 270 毫秒更改为 275 毫秒即可。CrUX BigQuery 具体化表中仍会提供 ECT 细分（现在来自 RTT 数据），因此 CrUX 信息中心等工具可以继续显示此细分。
BigQuery 数据集还包含按国家/地区（按 ISO 3166-1 定义）划分的数据。这样可以进行更深入的分析，有助于解释某些用户的效果指标为何较差。例如，我们可以通过查看 https://www.google.com 的数据来查看 Google 电话用户的数据：
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
然后，我们在地图上直观呈现数据：
https://www.google.com按国家/地区的第 75 个百分位手机 RTT（包含交互式图表的数据源
我们可以看到，虽然世界大部分地区（尤其是“西方世界”）的 RTT 非常出色，但撒哈拉以南非洲、中东部分地区和亚洲部分地区的 RTT 较差。事实上，由于使用完整数据会导致颜色偏差，因此图表的 RTT 上限为 500 毫秒，尤其是厄立特里亚的 75 百分位数为 3,850 毫秒！
当流量模式发生变化时，这也非常有用。例如，如果来自 RTT 较高的国家/地区的用户比例较高，则可能会导致 Core Web Vitals 统计数据较差，即使网站没有任何变化也是如此。
虽然网站无法直接改善 RTT，但通过向网站访问者提供此类数据，您可以更好地了解全球各地的网站用户。这也为未来的分析提供了许多机会，我们希望研究人员能从该数据集中发现有趣的洞见。
移除了 ECT 维度
2025 年 2 月版本中的最后一项变更是从 BigQuery 中弃用有效连接类型 (ECT) 维度（我们已于 2024 年 9 月从 API 中移除 RTT，并在当时引入了 RTT 指标作为替代项）。
如本文前面所述，通过 RTT 指标，您可以更精细地了解网站访问者的连接详情。您甚至可以根据这些直方图重新创建 ECT 分桶。（从技术层面来说，ECT 应是 RTT 和下行速度的组合，但 Chrome 仅使用 RTT。）
一个重要区别在于，ECT 是 CrUX 维度，这意味着其他指标可以按 ECT 进行细分。RTT 是 CrUX 指标，而非维度，因此您无法按 RTT 查看 LCP，只能按其他维度（设备类型和国家/地区）查看 RTT。
这可能听起来更具限制性，但从维度改为指标实际上会在 CrUX 中解锁更多数据。这是因为 CrUX 设有最低阈值，只有达到该阈值，我们才能显示数据。我们已在 2022 年将维度设为可选，这意味着我们移除了 ECT，或在必要时移除了设备，以便在更高级别进行报告，但对于大多数网页加载不存在的指标（Interaction to Next Paint [INP]、不同的导航类型，以及现在的 LCP 图片子部分），BigQuery 中的来源通常无法提供这些指标。
通过减少维度数量，数据的细分程度会降低，因此满足这些最低要求的来源数量会增加。1 月份，我们报告了 68.1% 的来源存在 INP 问题，而对于 12 月的数据集，我们仅报告了 64.5% 的来源存在 INP 问题。此机制也适用于此版本中的导航栏类型、LCP 子部分和资源类型，移除 ECT 维度对它们都有益。在 CrUX API 中，扩大的覆盖范围已于 2 月初生效。
为了与之前的数据集保持一致，ECT 列将保留在 BigQuery 中，物化视图中的 ECT 数据也将保持可用，但除了新的 RTT p75 和三分位数桶之外，还会基于 RTT 信息（3g 和 4g 之间的差异为 5 毫秒，如前所述）。
总结
在公共 CrUX 数据集中添加更多指标后，网站所有者和研究人员可以获得更多信息，以帮助诊断和最终解决性能问题。
作为一个公开数据集，我们在 CrUX 中显示的详细程度受到一定限制，例如，CrUX 中永远无法显示单个元素选择器。强烈建议希望获得此级别详细信息的网站所有者实现 RUM 解决方案，因为该解决方案不会受到此类限制。
不过，更高级别的汇总数据（例如本文中详述的数据）有助于您了解存在问题以及问题存在的原因。希望这些额外的数据对您有所帮助。如果您有任何反馈或疑问，请在讨论群组中告诉我们！