解读新一代 Web 性能体验和质量指标
衡量一个 Web 页面的体验和质量一直有非常多的工具和指标 ... 每次我们去关注这些指标的时候都会非常痛苦，因为这些指标真的是又多又难理解，测量这些指标的工具也非常多。
当看到最近发布的 Chrome 83 中又增加了几个性能指标的时候我头都大了...
然而不要着急，这些指标就是为了聚焦关注度和降低理解成本的，下面我们就来具体看一下，新增加的 Core Web Vitals 到底是什么东西？
如何衡量用户体验质量？
优化用户体验的质量一直都是是每个 Web 站点长期成功的关键，衡量用户体验的质量有很多方面。虽然用户体验的某些方面是需要基于特定于站点和上下文的，但是所有站点仍然有一组共同的指标——Core Web Vitals，这些指标包括加载体验、交互性和页面内容的视觉稳定性，他们构成了 2020 年核心 Web 健康指标的基础。
多年来，Google 提供了很多工具：(Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console's Speed Report) 来衡量和报告性能。一些开发人员是使用这些工具的专家，而大部分其他人则发现大量的工具和衡量标准都很难学习和使用。
网站开发者不应该为了理解他们交付给用户的体验的质量指标而成为性能专家。Web Vitals 计划的目的就是简化场景，降低学习成本，并帮助站点关注最重要的指标，即 Core Web Vitals。
Core Web Vitals
Core Web Vitals 是应用于所有 Web 页面的 Web Vitals 的子集，所有的站点开发者都应该关注一下，他们将在所有谷歌提供的性能测试工具中进行显示。每个 Core Web Vitals 代表用户体验的一个不同方面，在该领域是可衡量的，并反映了以用户为中心的关键结果的真实体验。
网页核心的性能指标应该是随着时间的推移而不断演变的。当前 2020 年主要关注用户体验的三个方面——加载、交互性和视觉稳定性:
Largest Contentful Paint (LCP): 衡量加载体验：为了提供良好的用户体验，LCP应该在页面首次开始加载后的2.5秒内发生。First Input Delay (FID): 衡量可交互性，为了提供良好的用户体验，页面的FID应当小于 100毫秒。Cumulative Layout Shift (CLS):衡量视觉稳定性，为了提供良好的用户体验，页面的CLS应保持小于 0.1。
下面我们来详细介绍这三种性能指标：
LCP
加载体验的衡量
衡量 Web 页主要内容的加载速度是众多开发者一直在关注的一个点，而且可衡量的指标非常多。
比如最早的 load、DOMContentLoaded 事件，用这两个事件来衡量页面加载速度是非常糟糕的，因为它们不一定与用户在屏幕上看到的内容相对应。
以用户为中心的更新性能指标（例如First Contentful Paint（FCP））它只能捕捉加载体验的最开始。如果页面最开始显示的是一个 loading 动画，那这个指标就很难关注了。
后来，业界开始建议使用比如 First Meaningful Paint (FMP) 和 Speed Index (SI)（都可以在 Lighthouse 中获取）等性能指标来帮助捕获初次渲染后的更多加载体验，但是这些指标非常复杂，难以解释，而且误报率也比较高。
什么是 LCP
Largest Contentful Paint (LCP) 用于衡量标准报告视口内可见的最大内容元素的渲染时间。为了提供良好的用户体验，网站应努力在开始加载页面的前 2.5 秒内进行 最大内容渲染 。
相比 FCP ，这个指标就非常有价值了，因为这个值是根据页面加载渲染不断变化的，如果页面有一个 lodaing 动画，然后才渲染出具体内容，那么这个指标计算出来的就是具体内容的加载速度，而非 lodaing 动画的加载速度。
LCP 考虑哪些元素
LCP 目前并不会计算所有元素，因为这样会使这个指标变得非常复杂，它现在只关注下面的元素：
元素元素元素- 通过
url()函数加载背景图片的元素 - 包含文本节点或其他内联文本元素子级的块级元素。
为了在开始时保持简单，将元素限制到这个有限的集合是有意的。随着研究的深入，将来可能会添加更多的元素。
如何计算 LCP ?
页面上最大的元素即绘制面积最大的元素，所谓绘制面积可以理解为每个元素在屏幕上的 “占地面积”，如果元素延伸到屏幕外，或者元素被裁切了一部分，被裁切的部分不算入在内，只有真正显示在屏幕里的才算数。
图片元素的面积计算方式稍微有点不同，因为可以通过 CSS 将图片扩大或缩小显示，也就是说，图片有两个面积：“渲染面积”与“真实面积”。在 LCP 的计算中，图片的绘制面积将获取较小的数值。例如：当“渲染面积”小于“真实面积”时，“绘制面积”为“渲染面积”，反之亦然。
页面在加载过程中，是线性的，元素是一个一个渲染到屏幕上的，而不是一瞬间全渲染到屏幕上，所以“渲染面积”最大的元素随时在发生变化。
如果元素被删除，LCP算法将不再考虑该元素，如果被删除的元素刚好是 “绘制面积” 最大的元素，则使用新的 “绘制面积” 最大的元素创建一个新的性能条目。
该过程将持续到用户第一次滚动页面或第一次用户输入（鼠标点击，键盘按键等），也就是说，一旦用户与页面开始产生交互，则停止报告新的性能指标。
在以上两个时间轴中，最大的元素随内容加载而变化。在第一个示例中，新内容被添加到 DOM 中，并且更改了最大的元素。在第二个示例中，布局发生更改，以前最大的内容从视口中删除。通常情况下，延迟加载的内容要大于页面上已存在的内容。
改善 LCP
LCP较差的最常见原因是：
- 服务器响应时间慢
- 阻断渲染的
Javascript和CSS - 资源加载时间慢
- 客户端渲染
所以我们从上面的角度去考虑改善 LCP：
优化服务器
这个很好理解，浏览器从服务器接收内容所需的时间越长，则在屏幕上呈现任何内容所花费的时间就越长。更快的服务器响应时间可以直接改善包括 LCP 在内的所有页面加载指标。
衡量服务器相应时间有一个专门的指标：首字节相应时间（TTFB）是最初的网络请求被发起到从服务器接收到第一个字节这段时间，它包含了 TCP 连接时间，发送 HTTP 请求时间和获得响应消息第一个字节的时间。你可以尝试在下面几个方便优化 TTFB ：
- 缓存
HTML离线页面，缓存页面资源，减少浏览器对资源的请求。 - 尽量减小资源阻断渲染：
CSS和JavaScript压缩、合并、级联、内联等等 - 对图片进行优化。转化图片的格式为
JPG或者WEBP等等的格式，降低图片的大小，以加快请求的速度。 - 对
HTML重写、压缩空格、去除注释等。减少HTML大小，加快速度。 - 使用
preconnect尽快与服务器建立链接、使用dns-prefetch尽快进行DNS查找。 - 使用
CDN加快请求速度
优化阻断渲染的资源
JavaScript 和 CSS 都是会阻断页面渲染的资源，需要尽可能的对 CSS 和 JavaScript 文件进行压缩、延迟加载首屏无需使用的 JavaScript、内联关键的 CSS 等来减小阻断时间。
优化资源加载时间
刚才我们上面提到的这些资源，如果在首屏进行渲染，则加载这些元素所花费的时间将直接影响 LCP 。
元素元素元素- 通过
url()函数加载背景图片的元素 - 包含文本节点或其他内联文本元素子级的块级元素。
你可以使用下面的手段进行优化：
- 对图片进行优化。转化图片的格式为
JPG或者WEBP等等的格式，降低图片的大小。 - 对重要的资源进行预加载，比如为
style标签添加rel="preload"属性 - 使用
Gzip和Brotli压缩页面资源，降低传输时间 - 使用
service worker缓存资源
服务端渲染
使用服务端渲染可以确保首先在服务器上呈现页面内容，可以有效改善 LCP，但是相比客户端渲染的缺点是会加大页面从而影响 TTFB、服务端渲染需要等待所有 js 执行完毕后才能相应用户输入，这会使交互体验变差。
FID
第一印象
我们都知道留下一个好的第一印象是多么重要。在网络上，一个好的第一印象可以决定一个人是不是可以成为一个网站的忠实的用户，或者是离开以后再也不会回来。问题是，什么能给人留下好印象，你如何衡量你可能给用户留下什么样的印象?
在网络上，第一印象可以有很多种不同的形式——我们对网站的设计和视觉吸引力有第一印象，对其速度和响应能力也有第一印象。
开发者们使用 First Contentful Paint（FCP） 可以衡量对网站加载速度对第一印象 。但是，网站可以在屏幕上绘制像素的速度只是一部分，同样重要的是用户尝试与这些像素进行交互时你的网站的响应速度！
什么是 FID
FID（ First Input Delay） 即记录用户和页面进行首次交互操作所花费的时间 。FID 指标影响用户对页面交互性和响应性的第一印象。为了提供良好的用户体验，站点应努力使首次输入延迟小于 100 毫秒。
FID 发生在 FCP 和 TTI 之间，因为这个阶段虽然页面已经显示出部分内容，但尚不具备完全的可交互性。这个阶段用户和页面交互，往往会有较大延迟。
如上图所示，浏览器接收到用户输入操作时，主线程正在忙于执行一个耗时比较长的任务，只有当这个任务执行完成后，浏览器才能响应用户的输入操作。它必须等待的时间就此页面上该用户的 FID 值。
例如，以下所有 HTML 元素都需要在响应用户交互之前等待主线程上正在进行的任务完成：
- 文本输入框，复选框和单选按钮（
，