我们已经知道性能的重要性，但当我们讨论性能的时候，让一个网页变得跟快，具体是指哪些？
事实上性能是相对的:
- 一个网站可能一个用户感觉很快，但对其他用户感觉很慢
- 两个网站的loading结束时间是一样的，但其中一个你感觉比另一个要快
- 一个网站加载的很快，但页面长时间不可交互
所以在讨论性能的时候，精确的、可量化的指标很重要。
虽然说某一个指标可能是客观的，可量化的，但对我们实际去评价性能可能没什么帮助。
定义指标
以往，开发者都通过 load 事件来衡量性能。load 是页面生命周期中的明确的时刻，但这个时刻用户并不关心。
举个例子，服务器可能很快的就返回了一个很小的页面，但在 load 事件之后推迟了若干秒来获取内容并展示。虽然这种页面 load 很快，但实际上用户看到内容则是在之后的若干秒，load 的时间跟用户实际感知的不一样。
为了确保指标与用户相关，Chrome团队围绕一系列问题定制了框架:
- 是否发生了: 跳转是否成功？服务器是否有响应？
- 是否有用: 是否渲染了足够的内容供用户查看？
- 是否可用: 用户是否可交互？或者页面卡住？
- 是否用的爽: 交互是否顺畅？自然？无延后？无卡顿？
指标的分类
- 感知加载速度: 页面加载完并给用户呈现了展示内容
- 加载响应: 页面加载完到js执行
- 运行时响应: 页面加载完之后，到页面可交互
- 视觉稳定性: 页面上是否有干扰元素，例如预期之外的滚动或者移动
- 流畅性: transition和animation是否流畅，帧率是否保持在60
鉴于以上的所有分类，我们应该清楚地意识到没有单一的指标可以捕获所有性能特征。
常见的性能指标
- First contentful paint (FCP): 从页面开始加载，到页面任意内容渲染在屏幕上的时间。(实验属性，现场数据)
- Largest contentful paint (LCP): 从页面加载开始，到页面上最大的文本块或者图片元素渲染在屏幕上的时间。(实验数据，现场数据)
- First input delay (FID): 用户第一个交互行为，比如点击链接、点击按钮等，到浏览器实际响应这次交互的时间。(现场数据)
- Time to Interactive (TTI): 从页面开始加载，到内容呈现，初始js加载完成，再到可以立刻响应用户交互的时间。(实验数据)
- Total blocking time (TBT): 在FCP和TTI之间的时间，即页面可见到可交互的时间，代表了主线程被阻塞无法响应用户交互。（实验数据）
- Cumulative layout shift (CLS): 从页面开始加载，到页面生命周期变为隐藏之间的所有意外的布局变化的累计分数。(实验数据，现场数据)
以上指标可以检测大部分的与用户相关的性能影响，但也不代表全部。
在某些情况下，会引入新的指标来覆盖缺失的区域，但其他情况下最好的指标是针对你的网站量身定制的。
自定义指标
有时候你的站点可能需要一些额外的指标来捕获整个性能图。举个例子，LCP的指标，如果最大的文本块或者图片元素不是你的网站的主要内容，这个指标则失去了原本的意义。
为了应对这些情况，Web性能工作小组定制了一些标准的底层API，帮你可以实施自己的自定义指标:
- User Timing API
- Long Tasks API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- Server timing
总结
本文只是一个常见性能指标的一个简要介绍，后面会针对每一个指标做更详细的介绍，以及在项目中的实际应用。
参考
https://web.dev/user-centric-performance-metrics/