分别对应响应、动画、空闲和加载，自上而下的在各个步骤延伸出各种优化手段，具体的各阶段介绍可以看 Measure performance with the RAIL model[2] 这篇文章，本文主要专注于讲解如何去定义这些阶段的性能好坏。

性能监控的种类

然后需要了解一下性能监控的种类，性能监控分为两种：

• 合成监控(Synthetic Monitoring，SYN)是一种模拟网页加载或者脚本运行来测量性能指标的方式，输出网页性能报告。这种方式的价值在于提前发现可能存在的性能问题，不依赖于用户上报。Lighthouse[3] 就是谷歌开发的非常著名的一种合成测试工具，它既可以作为浏览器插件运行，也可以作为 cli 脚本，甚至以程序化的方式运行在你的 Node.js 代码中。
• 真实用户监控(Real User Monitoring，RUM)是记录用户真实操作的一种被动监控，它的特点是用户真实的网页交互中去评估和记录性能数据。比如咱们常说的性能监控 sdk，就是为此而引入的。本文所介绍的 web-vitals 正是为了这种类型的监控而生。

合成监控和真实用户监控相辅相成，前者用于在实验室环境下提前发现一些性能问题;后者则深入到真实世界，和用户设备、网速、环境等息息相关。

在此前提之下，谷歌也把性能指标分为两类：

• 实验室指标(In the lab)：使用工具在一致的环境中模拟页面加载。
• 真实指标(In the field)：在真实用户环境中加载并且和用户交互。

核心性能指标

Web Vitals 其实是谷歌发起的一项倡议，统一关键性能的标准，帮助网站开发者去统计最重要的指标，简化了许多复杂的概念。

基于长期以来的性能指标优化体验，最新的性能指标主要专注于加载、交互、视觉稳定，综合下来就是下面的 3 个指标：

• Largest Contentful Paint (LCP)[4]: 最大内容绘制，是用来测量加载的性能。最好保证在 2.5 秒以内出现。
• First Input Delay (FID)[5]: 第一次输入延迟，用于测量可交互性。应该在 100 毫秒以内。
• Cumulative Layout Shift (CLS)[6]：累计布局位移，用于测量视觉稳定性。这个指标应该小于 0.1。

很多国内的文章会提到 First Meaningful Paint (FMP)，也就是首次有意义的渲染，但是这个指标其实已经在 Lighthouse 6.0 中被废弃了，原因在于页面的任何细微差异对这个指标的影响都太大了，带来了双峰分布(bimodal distribution)的不一致性问题。而且这个测量太依赖浏览器的实现细节了，意味着没法在所有浏览器中标准化。

目前可以使用 Largest Contentful Paint (LCP)[7] 来替代它。

测量核心指标

这些核心指标，目前都可以利用 web APIs 在 JavaScript 中进行测量。

使用 web-vitals

为了封装一些细节差异，谷歌提供了 GoogleChrome/web-vitals[8] 这个轻巧、准备好用于生产的包，它只是 web APIs 的一层封装，用户不需要再关心指标的收集时机，环境判断等问题。