共计 2721 个字符，预计需要花费 7 分钟才能阅读完成。
本文是译文，关注 Web Vitals Metrics，翻译系列文章中的 01 篇
原文链接：Largest Contentful Paint (LCP)
前言
始终以来，对开发者来说掂量页面加载中次要内容加载、显示的速度都比拟艰难。因为 Load 和 DOMContentLoaded 跟屏幕上用户所见内容并无必然的关系，所以不够好（它们不是面向用户的指标）。FCP（First Contentful Paint）是基于用户维度的指标，但只关注页面加载的最后阶段，如果页面上存在闪现或者 loading 组件，也无奈反映出用户关注的次要内容是何时加载的。起初咱们举荐应用 FMP 和 SI（LightHouse6 个指标之一），实际上它们也是简单的、含糊的，甚至是谬误的，并不能精确辨认页面次要内容的加载机会。简略为王，钻研后发现：
页面加载阶段最重要的内容往往是页面渲染区域最大的那局部内容。
1 LCP 定义和规范
什么是 LCP？LCP 反映的是从页面开始加载到页面视口上最大的图片或者文本块渲染的工夫。LCP<2.5s 意味着得分是 GOOD。
1.1 LCP 中的 Contentful 元素蕴含哪些？
哪些元素可能是 LC 的候选人呢？<img>、svg中的 <image>、<video>、含有用url() 设置背景图的元素、含文本节点或者内联子元素的块级元素 。
成心在一开始设定元素汇合是为了简化探讨，后续随着钻研的停顿，也会一直增加比方：<svg>和<video>。
1.2 元素大小如何掂量？
LCP 元素的大小是指 视口上可见元素的大小（不蕴含超过视口元素的大小、产生剪裁的元素、不可见的元素）。对于扭转了固有大小的图片来说，大小要么是图片可见的大小、要么是固有的大小。例如：放大的图片的大小只计算其显示的大小，而放大的图片的大小，只计算其固有的大小。对于文本元素来说，只会计算其文本节点的大小。对于所有的元素来说，都不将 css 中设置的 margin、padding 和 border 计算在内。
1.3 何时产生 LCP？（对于它的细节）
web 页面加载是分步进行的，因而，LC 会产生扭转。为了应答这种状况，浏览器散发了一个类型为 largest-contentful-paint 的 PerformanceEntry，用于当浏览器绘制了第一帧时辨认 LC 元素。之后，当渲染后续的帧时，只有 LC 元素发生变化，浏览器又会散发其它的PerformanceEntry。
例如：页面中存在文本和 hero 图片，一开始浏览器可能渲染的是文本，此时浏览器就会散发一个其 element 援用指向 <p> 或者 <h1> 的 PerformanceEntry；之后，一旦 hero 图片实现加载，浏览器又会散发一个 element 援用指向 <img> 的类型为 largest-contentful-paint 的 Entry。
LC 元素只能是曾经渲染了的可见元素，因而，刚开始可能会有其余的小一点的元素被检测为 LC 元素，但只有更大的元素渲染实现，就会通过 PerformanceEntry 对象更新成为最新的。曾经被检测为 LC 的元素如果从视口中移除了，只有没有更大的元素渲染，它就始终是 LC 元素。当用户与页面进行交互当前，浏览器就进行散发新的 Entry。
加载工夫和渲染工夫：基于平安思考，缺失 Timing-Allow-Origin 响应头的图片的渲染工夫戳将不会给裸露给跨域图片。只会裸露其渲染工夫。上面例子展现的是渲染工夫无奈取得的元素解决状况。咱们举荐尽量加上 Timing-Allow-Origin 响应头以使后果更加准确。
除了上述的 LC 元素的呈现工夫不确定，元素的布局和大小也会发生变化。为了升高计算和散发 PerformanceEntry 带来的性能损耗，元素大小或者地位的变动不会产生新的 LC 候选元素 ，只会思考视口上元素的初始大小和地位。这也就意味着那些初始阶段不渲染在屏幕上，之后又渲染进去的图像将不会被标记检测。这也意味着那些初始加载在视口上之后又不再显示的元素依然会标记其初始在视口上的大小。
例子：
上述图中两条工夫线外面，LC 元素都产生了变动。第一个例子一开始最大的 LC 被随后呈现的较大 LC 比上来了；第二个例子，之前最大的 LC 不存在了，被新的取代。
页面加载过程中前面加载的内容比之前的大的状况很常见，上面的图展现了页面加载实现之前 LCP 的状况。
第一个例子：logo 加载较早，即便其它元素逐步加载它始终放弃着是 LC 元素。第二个例子：在图片、logo 加载齐全之前，文本段落是 LC 元素。因为单个图片仍然比段落小，整个加载过程它始终是 LC 元素。
3 测量 LCP 的工具有哪些？
咱们把剖析工具分为：Field 现场工具和 Lab 开发工具。
Field 工具
Chrome User Experience Report
PageSpeed Insights
Search Consol
JS lib: web-vitals
Lab 工具
Chrome DevTool
LightHouse
WebPageTest
JavaScript
（1）Largest Contentful Paint API + PerformanceObserver
new PerformanceObserver((entryList) => {for (const entry of entryList.getEntries()) {console.log('LCP candidate:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});代码中的例子对每个 LCP 候选人都 log 进去了。一般来说，最终 entry 的 startTime 即为 LCP，但也存在例外的一些状况。比方：后盾 tab 页、后退后退缓存、iframe 中的 LCP 会被疏忽等状况。
（2）利用开发好的 Javascript 库，能够帮忙咱们屏蔽这些细节，用法如下：
import {getLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
getLCP(console.log);4 如果最大元素并非最重要的当如何？
此时就须要用到定制指标的 Element Timing API 了。此处不做剖析。
5 影响 LCP 的四个因素，
后续章节将针对性的给出优化计划。影响 LCP 的四个方面包含了：
（1）申请阶段迟缓的服务端响应；
（2）渲染阶段阻塞的 JS 和 CSS；
（3）资源加载工夫；
（4）客户端渲染。
如何优化 LCP，请参阅优化 LCP。其它能够晋升 LCP 的优化指南，能够参阅：
1. 优化要害渲染门路
2. 优化 CSS
3. 优化 JavaScript
4. 优化图片
5. 优化字体
6.PRPL 模式应用