页面的 最大内容渲染时间 (LCP) 很难改进，通常涉及多个变动部分和权衡。这篇文章着眼于来自 Web 上真实页面加载的字段数据，以确定开发人员应将优化工作重点放在哪里。
经典的 LCP 建议：减小图像尺寸！
对于 Web 上的大多数页面，LCP 元素都是图像。那么很自然地会认为，改进 LCP 的最佳方法是优化您的 LCP 图像。
在 LCP 引入以来的五年左右时间里，这通常是主要的建议。确保您的图像尺寸适当并充分压缩，并且在您进行操作时，可以考虑使用 21 世纪的图像格式。Lighthouse 甚至有 三项 不同的 审核 来提出这些建议。
之所以这是如此常见的建议，部分原因是过多的字节很容易测量，而图像压缩工具也很容易推荐。根据您的构建和部署管道，这也可能很容易实施。
如果是这样，那就去做吧！向您的用户发送更少的字节几乎总是有益的。Web 上有许多站点仍在提供不必要的大型图像，即使是基本压缩也可以修复这些问题。
但是，当我们开始查看 Chrome 中用户的字段性能数据，以了解 LCP 时间通常花费在哪里时，我们发现图像下载时间几乎永远不是瓶颈。
相反，LCP 的其他部分是更大的问题。
LCP 子部分分解
为了了解改进 LCP 的最大机会领域是什么，我们查看了 LCP 子部分的数据，如优化 LCP中所述。
虽然每个页面和每个框架可能采用不同的方法来加载和显示成为页面 LCP 元素的元素，但每个页面和每个框架都可以分为以下子部分
引用该文章，子部分是
- 首字节时间 (TTFB)
- 从用户发起页面加载到浏览器收到 HTML 文档响应的第一个字节的时间。
- 资源加载延迟
- TTFB 和浏览器开始加载 LCP 资源之间的时间。如果 LCP 元素不需要资源加载来渲染，则此时间为
0。 - 资源加载持续时间
- 加载 LCP 资源本身所需的时间。如果 LCP 元素不需要资源加载来渲染，则此时间为
0。 - 元素渲染延迟
- LCP 资源完成加载和 LCP 元素完全渲染之间的时间。
真实导航性能数据
| LCP 评级 | TTFB (毫秒) | 图像加载延迟 (毫秒) | 图像加载持续时间 (毫秒) | 渲染延迟 (毫秒) |
|---|---|---|---|---|
| 良好 | 600 | 350 | 160 | 230 |
| 需要改进 | 1,360 | 720 | 270 | 310 |
| 差 | 2,270 | 1,290 | 350 | 360 |
在这篇文章中，我们使用了来自 Chrome 中具有子资源图像 LCP 的页面导航的数据，以查看 LCP 子部分。我们之前看过这类数据，但从未从字段数据中看过，以了解真实用户在等待页面 LCP 时花费的时间。
与 Core Web Vitals 一样，我们采用了 CrUX 数据集中每个来源的每个 LCP 子部分的第 75 百分位数 (p75)，从而得出四个 p75 值分布（每个子部分一个）。为了总结这些分布，我们针对四个 LCP 子部分中的每一个，取了所有来源的这些值的中位数。
最后，我们根据来源在第 75 百分位数时是否具有“良好”、“需要改进”或“差” LCP，将来源分为不同的桶。这有助于显示具有良好 LCP 的来源与具有差 LCP 的来源之间的区别。
减小 LCP 图像的尺寸？这次使用数据
加载持续时间衡量的是获取 LCP 资源（在本例中为图像）所需的时间。此时间通常与图像中的字节数成正比，因此所有性能建议都旨在减少字节数。
在查看早期图表中时间的去向时，一个突出的点是，在图像加载持续时间上花费的时间不多。事实上，它是所有 LCP 桶中最短的 LCP 子部分。与良好 LCP 的来源相比，差 LCP 的来源的加载持续时间更长，但这仍然不是时间主要花费的地方。
大多数具有差 LCP 的来源在下载 LCP 图像上花费的时间不到其 p75 LCP 时间的 10%。
是的，您应该确保优化您的图像，但这只是改进 LCP 的一部分。并且从这些数据中可以清楚地看出，对于 Web 上的典型来源，无论压缩方案多么复杂，LCP 整体的潜在毫秒级增益都很小。
最后一个意外：缓慢的加载持续时间曾经通常归咎于移动设备和移动网络的质量。我们可能曾经期望一部典型的手机下载同一张图像的时间是使用有线连接的台式机的几倍。数据表明情况不再如此。对于具有差 LCP 的来源，移动设备上的中位数 p75 图像加载持续时间仅比台式机慢 20%。
首字节时间 (TTFB)
对于发出网络请求的导航，TTFB 始终需要一些时间。进行 DNS 查找和启动连接需要时间。并且您无法战胜物理定律：请求必须通过真实世界的电线和光缆才能到达服务器，然后响应必须返回。即使是具有良好 LCP 的中位数来源，在其第 75 百分位数时，TTFB 也花费了超过半秒的时间。
但是，良好和差 LCP 来源之间的 TTFB 差异显示了改进的机会。对于至少一半的差 LCP 来源，2,270 毫秒的 p75 TTFB 本身几乎可以保证 p75 LCP 不能快于 2.5 秒的“良好”阈值。即使适度减少该时间百分比，也意味着 LCP 的显着改进。
您可能无法战胜物理定律，但可以做一些事情。例如，如果您的用户通常与您的服务器位于非常不同的位置，则 CDN 可以使您的内容更靠近他们。
有关更多信息，请参阅优化 TTFB 指南。
资源加载延迟，被忽视的缓慢 LCP 罪魁祸首
如果 TTFB 可以改进，但任何改进都受物理定律的限制，则资源加载延迟有可能被消除，实际上仅受您的服务架构的限制。
此子部分衡量从 HTML 响应的第一个字节到达 (TTFB) 到浏览器开始请求 LCP 图像之间的时间。多年来，我们一直专注于下载 LCP 图像需要多长时间，但我们经常忽略在浏览器甚至被告知开始下载之前浪费的时间。
具有差 LCP 的中位数站点等待开始下载 LCP 图像的时间几乎是其实际下载时间的四倍，在 TTFB 和图像请求之间等待 1.3 秒。这超过了 2.5 秒 LCP 预算的一半在一个子部分中消失了。
依赖链是加载延迟时间长的常见原因。在更简单的情况下，页面加载样式表，浏览器在进行布局后，设置背景图像，该背景图像将最终成为 LCP。所有这些步骤都必须在浏览器甚至知道开始下载 LCP 图像之前发生。
使用 HTTP Archive 公共爬网数据，该数据记录从 HTML 文档到 LCP 图像的网络请求的“发起者”链，您可以看到请求链长度与较慢 LCP 的明显相关性。
关键是要尽快让浏览器知道 LCP 将是什么，以便它可以开始加载它，即使在页面布局中没有它的位置之前。有一些工具可用于实现此目的，例如 HTML 中的经典 <img> 标记，以便 预加载扫描器可以快速找到它 并开始下载它，或者用于非 <img> 的图像的 <link rel="preload"> 标记（或 HTTP 标头）。
帮助浏览器确定要优先处理哪些资源也很重要。如果您的页面在页面加载期间发出大量请求，则尤其如此，因为浏览器通常在许多资源加载并且发生布局后才知道 LCP 元素将是什么。使用 fetchpriority="high" 属性 注释可能的 LCP 元素（并确保避免 loading="lazy"）可以清楚地告知浏览器立即开始加载资源。
渲染延迟
渲染延迟衡量从浏览器加载并准备好 LCP 图像开始，但由于某种原因在屏幕上显示之前存在延迟的时间。有时，这是在图像准备就绪时阻止主线程的长时间任务，在其他情况下，这可能是显示隐藏元素的 UI 选择。
对于 Web 上的典型来源，似乎没有巨大的渲染延迟机会，但在优化期间，您有时可以从以前在其他子部分中花费的时间中创建渲染延迟。例如，如果页面开始预加载 LCP 图像，使其可以快速可用，则将不再存在长时间的加载延迟，但是如果页面本身尚未准备好显示图像（例如来自大型渲染阻塞样式表或客户端渲染应用程序，该应用程序必须在显示任何内容之前完成加载所有 JavaScript），则 LCP 仍然会比应有的速度慢，并且等待花费的时间现在将显示为渲染延迟。这就是为什么服务器端渲染或静态 HTML 在 LCP 方面通常具有优势。
如果您的内容受到影响，请阅读有关优化渲染延迟的更多建议。
检查所有这些子部分
很明显，要有效地优化 LCP，开发人员需要全面地查看页面加载，而不仅仅是专注于优化图像。检查 LCP 时间的每个部分，因为可能存在更大的改进机会。
为了在字段中收集此数据，web-vitals 库的归因构建包括 LCP 子部分的计时。Chrome 用户体验报告 (CrUX) 尚不包含所有这些数据，但它确实具有 TTFB 和 LCP 的条目，因此这是一个开始。我们希望在将来将用于这篇文章的数据包含在 CrUX 中，因此请继续关注有关该内容的更多新闻。
为了在本地测试 LCP 子部分，请尝试Web Vitals 扩展程序或本文中的 JavaScript 代码段。Lighthouse 还在其“最大内容渲染元素”审核中包含了分解。在 DevTools Performance 面板中查找更多 LCP 子部分建议，即将推出。