LCP 图片子部分和 RTT 现已在 CrUX 中推出

发布时间:2025 年 2 月 11 日

2025 年 2 月发布的 Chrome 用户体验报告 (CrUX) 包含许多令人兴奋的新指标(以及经过更改的指标):

这两种报告都能让您更深入地了解 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 APICrUX 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 的其他第三方工具也将会显示这些有价值的数据:

CrUX 可视化中的 LCP 图片子部分图表,显示了四个子部分的两个数据点
CrUX 可视化中的 LCP 图片子部分。

在本例中,我们可以看到,对于某个热门媒体网站,资源加载时长是影响最小的组成部分。此网站真正有改进空间的是 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 可视化图表也已更新,可显示以下数据:

CrUX 可视化中的 LCP 资源类型图表,显示了两种资源类型的两个数据点。
CrUX 可视化中的 LCP 资源类型

例如,对于 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 可视化图表中:

CrUX 中的 RTT 图表:显示 RTT 数据的完整数据系列,以及最后两个数据点的分布细目
CrUX 可视化中的 RTT 数据。

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

然后,我们在地图上直观呈现数据:

按国家/地区显示的 RTT 可视化图,其中大多数国家/地区显示为各种深浅不同的绿色,而撒哈拉以南非洲、中东和中亚部分地区以及中国显示为黄色、橙色和红色。
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 信息(3g4g 之间的差异为 5 毫秒,如前所述)。

总结

在公共 CrUX 数据集中添加更多指标后,网站所有者和研究人员可以获得更多信息,以帮助诊断和最终解决性能问题。

作为一个公开数据集,我们在 CrUX 中显示的详细程度受到一定限制,例如,CrUX 中永远无法显示单个元素选择器。强烈建议希望获得此级别详细信息的网站所有者实现 RUM 解决方案,因为该解决方案不会受到此类限制。

不过,更高级别的汇总数据(例如本文中详述的数据)有助于您了解存在问题以及问题存在的原因。希望这些额外的数据对您有所帮助。如果您有任何反馈或疑问,请在讨论群组中告诉我们