如何通过子部件分析解决最大的内容绘制问题？

您是否在为缓慢的最大内容绘制 (LCP) 而苦恼？Google 新推出的 LCP 子部分可帮助您查明页面加载延迟的来源。现在，在 Chrome UX 报告中，这些数据可提供真实的访问者洞察，以加快您的网站速度并提升排名。Matt Zeunert 为您解析了什么是 LCP 子部分、它们对您的网站速度意味着什么以及如何衡量它们。

核心 Web 指标中的最大内容绘制(LCP) 衡量了从访问者的角度看网站加载的速度。它考察的是打开页面后多久才能看到最大的内容元素。如果您的网站加载缓慢，这对用户体验不利，也会导致您的网站在 Google 上的排名较低。

尝试修复 LCP 问题时，并不总是清楚应该关注什么。服务器是否太慢？图片是否太大？内容是否未显示？Google 最近一直在努力解决这些问题，推出了LCP 子部分，告诉您页面加载延迟来自何处。他们还将这些数据添加到Chrome UX 报告中，让您了解导致网站实际访问者延迟的原因！

让我们看看 LCP 子部分是什么、它们对您的网站速度意味着什么以及如何衡量它们。

四个 LCP 子部分

LCP 子部分将最大内容绘制指标分为四个不同的部分：

1. 首次字节时间 (TTFB)：服务器响应文档请求的速度。
2. 资源加载延迟：LCP 图像开始下载之前所花费的时间。
3. 资源加载时间：下载 LCP 图像所花费的时间。
4. 元素渲染延迟：LCP 元素显示之前的时间。

仅当最大的页面元素是图像或背景图像时，资源计时才适用。对于文本元素，加载延迟和加载时间组件始终为零。

如何测量 LCP 子部件

衡量每个组件对您网站 LCP 分数的贡献程度的一种方法是使用 DebugBear 的网站速度测试。展开“最大内容绘制”指标以查看与您的 LCP 分数相关的子部分和其他详细信息。

在这里，我们可以看到 TTFB 和图像加载持续时间合计占整体 LCP 得分的 78%。这告诉我们，这两个组件是开始优化的最有影响力的地方。

每个阶段都发生了什么？网络请求瀑布可以帮助我们了解每个阶段正在加载哪些资源。

LCP 图像发现视图将瀑布可视化筛选为与显示最大内容绘制图像相关的资源。在这种情况下，前三个阶段各包含一个请求，最后一个阶段快速完成，没有加载任何新资源。但这取决于您的特定网站，情况并非总是如此。

第一个字节的时间

显示最大页面元素的第一步是获取文档 HTML。

在此示例中，我们可以看到创建服务器连接并不需要花费太长时间。大部分时间都花在等待服务器生成页面 HTML 上。因此，为了改善 TTFB，我们需要加快该过程或缓存 HTML，以便我们可以完全跳过 HTML 生成。

资源加载延迟

我们要加载的“资源”是 LCP 图像。理想情况下，我们只需<img>在 HTML 顶部附近添加一个标签，浏览器就会立即找到它并开始加载它。

但有时，我们会遇到加载延迟，就像这里的情况一样。页面不会直接加载图像，而是使用lazysize.js图像延迟加载库，该库仅在检测到 LCP 图像将出现在视口中后才加载该图像。

部分加载延迟是由于必须下载该 JavaScript 库造成的。但浏览器还需要完成页面布局并开始渲染内容，然后库才会知道图像位于视口中。完成请求后，有一个 CPU 任务（橙色）会导致首次内容绘制里程碑，此时页面开始渲染。只有这样，库才会触发 LCP 图像请求。

我们如何优化它？首先，你可以使用原生loading="lazy"图像属性，而不是使用延迟加载库。这样，加载图像不再依赖于首先加载 JavaScript 代码。

但更具体地说，LCP 图像不应延迟加载。这样，浏览器就可以在 HTML 代码准备就绪后立即开始加载它。根据 Google 的说法，你应该努力完全消除资源加载延迟。

资源加载时长

加载持续时间子部分可能是最简单的：您需要先下载 LCP 图像，然后才能显示它！

在此示例中，图像从与 HTML 相同的域加载。这很好，因为浏览器不必连接到新服务器。

您可以使用其他技术来减少加载延迟：

• 使用提供更好压缩的现代图像格式。
• 以与显示尺寸相匹配的尺寸加载图像。
• 降低可能与 LCP 形象相冲突的其他资源的优先级。

元素渲染延迟

第四个也是最后一个 LCP 组件Render Delay通常是最令人困惑的。资源已加载，但由于某种原因，浏览器尚未准备好向用户显示它！

幸运的是，在我们目前看到的例子中，LCP 图像在加载后很快就出现了。渲染延迟的一个常见原因是LCP 元素不是图像。在这种情况下，渲染延迟是由渲染阻止脚本和样式表引起的。文本只能在加载完这些并浏览器完成渲染过程后才能显示。

您可能会看到渲染延迟的另一个原因是网站预加载 LCP 图像。预加载是一个好主意，因为它实际上消除了任何加载延迟并确保图像尽早加载。

但是，如果图片在页面渲染完成之前下载完成，您会看到页面渲染延迟增加。这很好！您已经整体提高了网站速度，但在优化图片后，您发现了一个新的瓶颈需要关注。

真实用户 CrUX 数据中的 LCP 子部分

在实验室测试中查看最大内容绘制子部分可以为您提供很多关于可以优化的地方的见解。但实验室中的 LCP 往往与真实用户的情况不符！

因此，Google 从 2025 年 2 月开始在 CrUX 数据报告中包含子部分数据。它尚未（尚未？）包含在 PageSpeed Insights 中，但您可以在 DebugBear 的“Web Vitals”选项卡中看到这些指标。

这里一个非常有用的信息是LCP 资源类型：它告诉您有多少访问者将 LCP 元素视为文本元素或图像。

即使是同一个页面，不同的访问者看到的内容也会略有不同。例如，根据设备尺寸，可以看到不同的元素，或者一些访问者会看到 Cookie 横幅，而其他访问者会看到实际的页面内容。

为了使数据更易于解释，Google 仅报告图像的子部分数据。

如果 LCP 元素通常是页面上的文本，那么子部分信息将不会有太大帮助，因为它不适用于大多数访问者。

但分解文本 LCP 相对容易：不属于 TTFB 分数的所有内容都会被延迟渲染。

使用真实用户监控来跟踪你网站上的子部分

实验室数据并不总是与真实用户的体验相符。CrUX数据是肤浅的，仅针对高流量页面进行报告，并且在更改推出后至少需要4 周才能完全更新。

这就是为什么像 DebugBear 这样的真实用户监控工具在修复 LCP 分数时非常有用。您可以跟踪网站上所有页面的分数，并为每个 LCP 子部分获取专用仪表板。