初代性能参考标准 - RAIL
在 Web Vitals 推出之前，Google 使用了一种名为 RAIL 的性能模型来衡量 Web 应用程序的性能。RAIL 模型将每个用户交互分为四个阶段：响应、动画、空闲和加载。
虽然 Web Vitals 已经取代了 RAIL 模型，但仍然可以使用 RAIL 模型来了解其应用程序的性能瓶颈，并采取相应的措施来优化其应用程序的性能。
RAIL 模型中的四个阶段是：
Response 响应
要求在 100 毫秒内响应用户输入。
Animation 动画
要求在 10 毫秒内生成一帧动画。
Idle 空闲
在空闲时间执行后台任务，以保持 Web 应用程序的响应性。
Load 加载
要求在 5 秒内加载并呈现页面内容。
现在的标准 - Web Vitals
Web Vitals 是 Google 推出的一组用于衡量网站性能的指标，相比之前更加可量化和可测量。观测的话，一般采用用户的75分位（第75百分位）比较有实际意义。
Core Web Vitals
其中最核心的三个指标被称为
Core Web Vitals ，现在我们一个一个来看。LCP（Largest Contentful Paint）
LCP 指的是最大内容绘制的时间，即视口内最大元素渲染的时间点。
相比于之前LightHouse中推荐的FMP、SI指标更加可以量化，更加稳定可靠。
标准中规定了以下元素类型才会纳入计算
（未来可能扩充其他元素，如
<svg>、 <video> 等）什么时候上报 LCP？
从开始渲染页面，就会不断的上报
largest-contentful-paint类型的 PerformanceEntry；再之后最大内容发生变化后会再次分发此事件。因此，我们只需要在页面加载完成时，上报最近一次 PerformanceEntry 即可。
FID（First Input Delay）
FID 指的是用户第一次和页面交互后（比如点击按钮），浏览器响应并处理事件的时间。
为了保证用户使用体验，应尽量做到 100 ms 或以内。
为什么需要关注首次输入？
作为开发者，我们会默认代码会在第一时间执行。但是浏览器执行 JS 本身是一个单线程的过程，一些 JS 资源的加载和网络请求都有可能导致输入的延迟。
另外，虽然每次输入的延迟都很重要，但其中首次输入代表了用户对网站响应度的第一印象，非常重要。
如何测量
以下是一个用 JavaScript 监听 FID 的例子
new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const delay = entry.processingStart - entry.startTime; console.log('FID candidate:', delay, entry); } }).observe({type: 'first-input', buffered: true});
CLS（Cumulative Layout Shift）
CLS 测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。
为了提供良好的用户体验，页面的 CLS 应保持在 0.1 或更少。
为什么需要关注？
如下图这种情况，页面的偏移会导致用户的操作受到干扰；另外偏移太过频繁也会导致网站使用体验不佳。
如何计算 CLS
布局偏移分数 = 影响分数 * 距离分数其中：影响分数代表了偏移元素的集合所占视口的比例，距离分数代表了偏移的距离占视口的比例；
如下图影响分数为 0.75，距离分数为 0.25
其他指标
FCP（First Contentful Paint）
首次内容绘制，开始加载到页面内容的任何部分在屏幕上完成。
TTFB（Time to First Byte）
页面返回首字节时间，用来判断页面资源返回速度。
如何查看网站的 Web Vitals？
LightHouse
Chrome Devtools 中的 LightHouse 可以支持性能的检测；
其中 Performance 这一项中就包含了各种 Web Vitals 的检测。
浏览器插件
官方提供了一个浏览器插件，在插件的popup中即可查看当前页面的各项指标。
web-vitals 库
官方也提供了一个 js 的库方便调用。
web-vitals
GoogleChrome • Updated Jun 26, 2024
使用示例
import {onCLS, onFID, onLCP} from 'web-vitals'; onCLS(console.log); onFID(console.log); onLCP(console.log);
