LCP

LCP 会报告视口内可见的最大图片、文本块或视频的渲染时间（相对于用户首次导航到网页的时间）

LCP 得分多少算好

为了提供良好的用户体验，网站应尽量将 Largest Contentful Paint 控制在 2.5 秒或更短的时间内。为确保大多数用户都能达到此目标值，一个合适的衡量阈值是网页加载时间的第 75 个百分位数，并按移动设备和桌面设备进行细分

考虑元素

<img> 元素（第一帧呈现时间适用于 GIF 或动画 PNG 等动画内容）
<svg> 元素中的 <image> 元素
<video> 元素（使用海报图片加载时间或视频的第一帧呈现时间，以较早者为准）
使用 url 函数加载背景图片的元素（而不是 CSS 渐变）
包含文本节点或其他内嵌级文本元素子元素的块级元素

FCP 衡量的是任何内容绘制到屏幕上的时间，LCP 衡量的是主要内容绘制到屏幕上的时间

如何确定元素的大小

为 LCP 报告的元素大小通常是指用户在视口中看到的大小。如果元素超出视口范围，或者元素的任何部分被剪裁或具有不可见的溢出，则这些部分不会计入元素的大小。

对于已从固有大小调整大小的图片元素，系统会报告较小的可见大小或固有大小。

对于文本元素，LCP 仅考虑可包含所有文本节点的最小矩形。

对于所有元素，LCP 均不会考虑使用 CSS 应用的外边距、内边距或边框

何时报告 LCP

网页通常分阶段加载，因此网页上最大的元素可能会发生变化。

为了处理这种潜在的变化，浏览器会在绘制第一帧后立即调度类型为 largest-contentful-paint 的 PerformanceEntry，以标识最大的内容元素。但是，在渲染后续帧后，每当 Largest Contentful Element 发生变化时，它都会调度另一个 PerformanceEntry。

例如，在包含文本和主推图片的页面上，浏览器可能最初只会渲染文本，此时浏览器会分派一个 largest-contentful-paint 条目，其 element 属性可能会引用 <p> 或 <h1>。稍后，主打图片加载完毕后，系统会分派第二个 largest-contentful-paint 条目，其 element 属性会引用 <img>。

只有在元素呈现并可供用户看到后，才能将其视为包含内容的最大元素。尚未加载的图片不计入“呈现”次数。在字体块期内，文本节点也不会使用 Web 字体。在这种情况下，系统可能会报告较小的元素为最大内容渲染时间元素，但一旦较大的元素完成渲染，系统就会创建另一个 PerformanceEntry。

除了延迟加载的图片和字体之外，网页可能会在有新内容可用时向 DOM 添加新元素。如果其中任何新元素的大小大于之前最大的有内容元素，系统也会报告新的 PerformanceEntry。

如果从视口中移除（甚至从 DOM 中移除）最大的内容元素，除非渲染出更大的元素，否则它仍然是最大的内容元素。

一旦用户与网页互动（通过点按、滚动或按键操作），浏览器就会停止报告新条目，因为用户互动通常会更改对用户可见的内容（这在滚动时尤其如此）

加载时间与呈现时间

出于安全考虑，对于缺少 Timing-Allow-Origin 标头的跨源图片，系统最初不会公开图片的呈现时间戳。而是仅公开了其加载时间（因为此信息已通过许多其他 Web API 公开）。

加载时间通常会在资源下载结束（资源时间戳中的 responseEnd）后稍微延迟，因为浏览器需要花费一些时间来处理资源（甚至在开始呈现资源之前）。不过，如果预加载了 LCP 资源或延迟了渲染，加载时间和渲染时间之间可能会有较大的间隔。

这可能会导致 Web API 报告的 LCP 时间早于 FCP，这似乎是不可能的。事实并非如此，但由于存在此安全限制，因此才会出现这种情况。

此问题已于 2024 年底得到解决，从 Chrome 133 开始，即使未提供 Timing-Allow-Origin，也可以使用稍微粗略的渲染时间。

不过，我们仍建议您尽可能设置 Timing-Allow-Origin 标头，以便获得更准确的指标，尤其是对于未包含这项近期变更的浏览器

如何处理元素布局和大小更改

为了降低计算和调度新性能条目的性能开销，对元素的大小或位置所做的更改不会生成新的 LCP 候选项。系统仅会考虑元素在视口中的初始尺寸和位置。

这意味着，最初在屏幕外呈现，然后转换到屏幕上的图片可能不会被报告。这也意味着，最初在视口中呈现但随后被推下、超出视野的元素仍会报告其初始的视口内大小

如果最大的元素不是最重要的元素

在某些情况下，网页上最重要的元素与最大的元素并不相同，开发者可能更感兴趣衡量这些其他元素的呈现时间。您可以使用 Element Timing API 实现此目的