目录
一、概述
记录前端性能监测的指标及部分监测手段。本文很多内容，参考掘金、CSDN等社区，如有侵权，可以联系我删除0.0。
二、性能优化指标
概述
想要优化网站性能，需先了解如何衡量一个网站的性能，如下所示，为常见的性能指标。
First Paint 首次绘制（FP）
First contentful paint 首次内容绘制 (FCP)
Largest contentful paint 最大内容绘制 (LCP)
First input delay 首次输入延迟 (FID)
Time to Interactive 首次可交互时间 (TTI)
Total blocking time 总阻塞时间 (TBT)
Cumulative layout shift 累积布局偏移 (CLS)FP & FCP
FP全称First paint，翻译为首次绘制，用于记录页面第一次绘制像素的时间。FCP全称First contentful paint，翻译为首次内容绘制，用于记录页面首次绘制文本、图片、非空白 Canvas 或 SVG 的时间。FP和FCP记录的是某一时刻。
FP记录首次绘制像素的时间，FP记录的那一刻，DOM内容还没开始绘制，只有当DOM内容发生变化，如渲染出一段文字，才会记录FCP。所以，FP记录时刻一定不会晚于FCP。FP和FCP是和白屏时间相关的指标，所以越小越好。2s内记录，则属于优秀的范围。
LCP
LCP全称Largest Contentful Paint，翻译为最大内容绘制，用于记录视窗内最大元素的绘制时间，该指标不是记录某一时刻，而是随着页面渲染，实时变化。注意，该指标会在用户首次交互后停止记录。
相比于FP和FCP，LCP更能体现页面性能的好坏。FCP仅仅记录内容开始加载的那一刻，但那时用户希望看到的内容并未呈现，而LCP会持续更新，可以告诉我们页面的主要内容何时呈现出来。如下图所示，2.5s内属于优秀范围。
TTI
TTI全称Time to Interactive，翻译为首次可交互时间。该指标计算略微复杂，需要满足以下三个条件。
1、从 FCP 指标后开始计算
2、持续 5 秒内无长任务（执行时间超过 50 ms）且无两个以上正在进行中的 GET 请求
3、往前回溯至 5 秒前的最后一个长任务结束的时间
这是一个很重要的用户体验指标，代表着页面何时能真正进入可用状态。毕竟光内容渲染快还不够，还要能迅速响应用户的交互。
FID
FID全称First Input Delay，翻译为首次输入延迟，用于记录在FCP和TTI之间，用户首次与页面交互时响应的延迟，如果其中有长任务发生的话，那势必会造成响应时间延长。如下图所示，Google推荐响应用户交互在100ms以内。
TBT
TBT全称Total Blocking Time，翻译为总阻塞时间，用于记录FCP到TTI之间所有长任务的阻塞时间总和。假如说在FCP到TTI之间页面总共执行了以下长任务（执行时间大于 50ms）及短任务（执行时间低于 50ms）。
那么每个长任务的阻塞时间就等于它所执行的总时间减去 50ms
所以对于上图的情况来说，TBT总共等于345ms。这个指标的高低其实也影响了 TTI 的高低，或者说和长任务相关的几个指标都有关联性。
CLS
CLS全称Cumulative Layout Shift，翻译为累计位移偏移，用于记录页面上非预期的位移波动。大家想必遇到过这种情况，页面渲染过程中，突然插入一张巨大的图片，或点击某个按钮，突然动态插入一块内容等等，诸如此类操作，非常影响用户体验。CLS就是为了这种情况而生的，计算公式如下。
CLS = 位移影响的面积 * 位移距离
以上图为例，文本移动了25%的屏幕高度距离（位移距离），位移前后影响了75%的屏幕高度面积（位移影响的面积），则CLS为0.25 * 0.75 = 0.1875
如上图所示，CLS推荐值小于0.1，越低说明页面越稳定，用户体验越好。
注意，并不是所有布局移动都是不好的，很多web网站都会改变元素的开始位置，只有当布局移动是非用户预期的，才是不好的。
三、三大核心指标
三大核心指标
Google在20年5月提出了Web Vitals，这是谷歌定义的衡量一个网站用户体验的基本指标。
在Web Vitals中，Core Web Vitals 是最核心的，它包含三个核心指标，分别为LCP、FID、CLS。谷歌为什么要新提出一个指标集呢，这是因为，在过去要衡量一个高质量网站，需要的指标太多，且有些指标计算很复杂，所以Google推出Web Vitals，就是为了简化这一过程，用户仅仅需要关注Web Vitals即可。
LCP
用于记录视窗内最大元素的绘制时间，该时间会随着页面渲染变化而变化。因为页面中的最大元素在渲染过程中可能会发生改变，另外该指标会在用户第一次交互后停止记录。LCP用来衡量加载体验，谷歌要求LCP最好在页面首次开始加载后的2.5s内发生。
LCP比FP、FCP、FMP更能体现一个页面的性能好坏程度，因为这个指标会持续更新。例如当页面出现骨架屏或Loading动画时FCP其实已经被记录下来了，但此时页面内容其实并未呈现。
LCP目前并不会计算所有元素，因为这样会使这个指标变得非常复杂，目前LCP仅关注下面的元素。
1、<img>元素
2、<image>元素内的<svg>元素
3、<video>元素
4、通过 url() 函数加载背景图片的元素
5、包含文本节点或其他内联文本元素子级的块级元素。假如发现LCP不达标，怎样优化呢，如下所示，LCP可能被这四个因素影响。
1、服务端响应时间
2、Javascript和CSS引起的渲染卡顿
3、资源加载时间
4、客户端渲染FID
首次输入的延迟时间，用于记录用户首次与页面交互时响应的延迟，即从用户首次与页面进行交互（即当他们单击链接、按钮、输入框等）到浏览器实际上能够响应该交互之间的时间。FID用于衡量页面交互性，谷歌要求页面的FID最好小于100ms。交互的响应速度越快，网页越流畅。
FID 在 FCP 和 TTI 之间，这个阶段页面已经部分呈现，但还不具备完全可持续交互的状态，如果其中有长任务发生的话那么势必会造成响应时间变长。
假如发现FID不达标，怎样优化呢，如下所示，FID可能被这四个因素影响。
1、减少第三方代码的影响
2、减少Javascript的执行时间
3、最小化主线程工作
4、减小请求数量和请求文件大小CLS
累计布局位移，用于衡量视觉稳定性，是一个重要的、以用户为中心的衡量视觉稳定性的指标，因为它有助于量化用户体验意外布局位移的频率。谷歌要求页面的CLS最好保持小于0.1。
在使用 app 时，经常会遇到这样的问题，当点击一个按钮时，突然按钮没有任何警告的移动，这对于用户来说体验是非常糟糕的。
为什么会发生这种毫无预警的移动呢？主要因为页面可能使用某些异步或DOM元素加载资源，或者动态将某些元素添加到页面上，或者具有未知维度的图像或视频，或者默认字体大小与后面真实呈现的字体不匹配、或者是动态调整大小的第三方广告或窗口小部件等等。
因此用CLS来衡量页面的累积布局偏移，偏移越大，得分越低。
注意，并不是所有布局移动都是不好的，很多web网站都会改变元素的开始位置，只有当布局移动是非用户预期的，才是不好的。
换句话说，当用户点击了按钮，布局进行了改动，这是ok的，CLS的JS API中有一个字段hadRecentInput，用来标识500ms内是否有用户数据，视情况而定，可以忽略这个计算。
那如果CLS不达标，怎样优化呢。我们可以根据以下原则来避免非预期布局移动。
1、图片或视屏元素有大小属性，或给他们保留一个空间大小，设置width、height
2、不要在一个已存在的元素上面插入内容，除了相应用户输入
3、使用animation或transition而不是直接触发布局改变四、怎么监测Web Vitals
方法一：NPM包
Google提供了一个小而美的npm包（web-vitals），如下图所示，可以监测如下指标。
使用方式如下所示。
npm install web-vitalsimport {getLCP, getFID, getCLS} from 'web-vitals';
getCLS(console.log);
getFID(console.log);
getLCP(console.log);方法二：Google插件
可以参考使用如下插件。
1、首先我们可以使用Lighthouse，在本地进行测量，根据报告给出的一些建议进行优化；
2、发布之后，我们可以使用PageSpeed Insights去看下线上的性能情况；
3、接着，我们可以使用Chrome User Experience Report API去捞取线上过去28天的数据；
4、发现数据有异常，我们可以使用DevTools工具进行具体代码定位分析；
5、使用Search Console’s Core Web Vitals report查看网站功能整体情况；
6、使用Web Vitals扩展方便的看页面核心指标情况如下图所示，使用web-vitals-extension来获取三大核心指标数据。
方法三：原生API
LCP
LCP还可以用JS API进行测量，主要使用PerformanceObserver接口，目前处理IE不支持，其他浏览器基本都支持了。
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP candidate:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});FID
FID还可以用JS API进行测量，主要使用PerformanceObserver接口，目前处理IE不支持，其他浏览器基本都支持了。
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});五、谷歌怎么查看JS内存使用情况
方式1：任务管理器
打开谷歌任务管理器，如下图所示，关注两个指标，其一内存占用空间，其二JS使用的内存。
1、内存占用情况：原生内存，Dom节点就是存在原生内存里面
2、JS使用的内存：代表JS堆内存，只需要关心括号里的实时值就可以了，JS对象就存在JS堆里面方法2：Performance
如下图所示，不断增加DOM元素，可以看到Nodes数量不断上升，但JS Heap却起起落落。
JS堆占用下降，放大看可以看到，每次下降都是GC（garbage collection 垃圾回收）执行过后。所以我们不但可以利用performance来看JS堆的使用情况，还可以看线程在执行什么任务，占用了多久时间。
方法3：Memory拍摄堆快照
通过任务管理器和Performance可以看到JS Heap的大小和趋势，但没办法看到堆里面的细节，这时候，我们可以通过Memory模块，拍摄一个快照，借此查看细节内容。
如下图所示，我们看到了堆里面的详情，其中特别关注shallow Size和Retained Size两列。
Shallow Size：浅层大小，是对象本身的大小（不包括它内部引用的对象），这个我们通常不太关注
Retained Size：保留大小，如果GC回收这个对象后，可以释放多少内存，这个我们非常关注如上图所示，第一个对象本身大小仅占35%，但GC回收后，可以释放54%的内存。这个是典型的小对象，导致大问题。对象本身不大，但是引用了一些大对象，使得这些大对象没办法被GC回收。
方法4：Performance Monitor
Performance Monitor监视器，可以理解为Performance的实时简化版，Performance可以录快照，可以看到每个点比较详细的信息，但不是实时的。
而Performance Monitor是实时的，但没办法像Performance一样看到那么多细节信息。
六、怎么查看GPU情况
如下图所示，使用电脑任务管理器查看。
