这是我参与「第五届青训营」笔记创作活动的第二十二天
为什么需要前端监控
问题是怎么发生的，我们是没有办法定位到的，由此，我们就想到能不能引入一套前端的监控体系来复现问题是怎么发生的，从而去做归因，改良我们的代码，改良我们的整套系统
➡️所以我们做业务和帮业务页面提高性能这两点是不冲突的，磨刀不误砍柴工，只有说把我们页面性能提升了，我们业务才能更好地去支持
概述：前端监控之常用性能指标
Web性能标准地诞生
包括SPA (Single Page Application)等思想的引入，也使得页面越来越重，使得前端也越来越需要关注性能
传统的性能指标
模型-1
模型-2
两个模型是相似的，模型2提出的时间较晚，也是我们现在标准浏览器正在使用的模型
以用户为中心的性能指标
由于传统模型的复杂性，提出了以用户为中心的性能指标
这六张图分别对应了性能指标的一个关键节点
- 第一张图是完全的白屏，可以看到没有任何的像素发生了渲染
- 第二张图也没什么内容，但有些像素点已经开始渲染了，我们可以认为是发生了第一个像素点的渲染，即FP (只要你往我屏幕上输出了像素点，我们就可以认为是FP发生了)
- 第三张图是首次有内容呈现出来的时间点(这里是出来了一个搜索框和一个Tab)，即FCP
- 第五张图，我们可以发现内容又多了一点，而且内容也更有意义一些，所以我可以称之为FNP
- 第六张图，它的几乎所有内容都渲染完成，用户可以真正地与页面进行交互了，称之为TTI，可以去度量我们完全加载主要资源的时间节点。在之前的五屏，用户都是不能与页面进行交互的，所以第六屏出来的时间越快，用户也就能越快与页面进行交互。(是前端监控中重要的性能指标)
SI
SI这个性能指标在前端中其实用的比较少，因为它的监控难度比较高一点，需要付出比较大的性能损耗来计算这个指标
FID
FID这个指标比较特殊，只用当用户和页面发生交互后，才会计算出这个指标，度量的是页面在加载完成之后，什么时候用户才开始使用到这个页面
为了更好地了解用户体验，引入了一些新的性能指标，比如用红框圈出来的这些
LCP
可以认为，LCP越快，用户就可以越早看到我们想要呈现给用户的内容的最主要部分 (最后一屏的BUY NOW，我们将其视为交互控件)。有些次要的内容可以之后再渲染出来，我们想要尽早把我们的主要内容呈现给用户，**所以LCP也是一个很重要的性能指标!
其实在前端监控实践中，其实是不会用到这个指标的，是因为我们还要兼顾我们监控当中的性能损耗，如果说我们前端监控让我们原来的这个页面产生了较大的性能损耗，那我们可以认为这个前端监控对业务造成了一个负影响。(当然前端是不可能不引入任何的性能损失的，我们一般是找到一个大家都比较能接受 | 比较居中的值，不会太去占用前端的性能，因为JS是一个单线程的模式，对于CPU密集型的任务是非常难以胜任的)
TBT
- 图中的黄色我们是指空闲时间，红色是指繁忙的时间
- 为什么我们要定义长任务这个概念呢：因为在JS线程运行的时候，它是会阻塞掉渲染的任务的，如果说我们超过了50ms，用户就会明显感觉到渲染的速度变慢了，并且页面渲染发生了卡顿，所以我们认为50ms是用户能够感知到一个极限，所以我们引入TBT，就可以看出从FCP到TTI之间，到底发生了多少次这种长任务的阻塞，让我们去计算长任务的一个总和 (可以看做页面首次加载出有意义的部分内容到可以交互之间用户到底需要阻塞多久，如果该项时间过长，会给用户带来较差的体验)
CLS
往小了说对用户视觉上的体验很差
往严重了说可能会造成用户的误触等问题
- 比较重要的几个指标，需要重点关注一下，FP，FCP，FMP，LCP，TTI，CLS
