【性能】7 分钟带你快速上手 Chrome Performance 面板

背景

在前端领域, 性能优化都是一个非常重要的组成部分，如何通过合理的手段尽可能地提高页面性能，是需要我们不断地努力要做到的，但在那之前, 性能排查又是让你能够对症下药的重要手段, 通过性能排查, 咱们才能清楚的知道页面中具体是什么原因影响了性能，Chrome DevTools给我们提供了2种常用方式 Audits和Performance，Audits可以对页面进行性能评分，同时，还会给我们提供一些优化建议。而Performance则提供了非常多的运行时数据，能让我们看到更多细节数据。下面主要介绍一下如何利用DevTools中的Performance面板来进行性能分析, 并排查性能问题。

Performance 面板介绍

首先在新的无痕窗口打开网页(使用无痕的目的是尽可能减少浏览器插件和缓存对页面的影响)，打开Chrome DevTools 切换到 Performance 下可以看到以下界面：

上图1、3区域按钮可以用来控制性能数据记录，黑色按钮可以记录交互阶段的性能数据，圆形箭头按钮用来记录加载阶段的性能数据。

上图2区域可以设置当前页面的网络加载速度与CPU运算速度, 通过这2项可以去尽可能的模拟移动端设备的加载环境。

通过点击3区域内的reload刷新按钮,会刷新页面并记录性能数据, 并得到以下性能报告。

整个页面性能数据分析报告从上至下可简单分为三个部分.

第一部分：网页性能总览图

详情展开

这里最主要是整体的界面渲染的时候，每个时间段执行的事件顺序，通过上图我们就能知道我们每个时间段（精确到毫秒）都做了什么，当鼠标放上去的时候，我们还可以大图的形式去查看我们每个时间段界面的渲染情况，Performance 就会将几个关键指标，诸如FPS（每秒帧数情况）、CPU（CPU占用情况）、NET（网络资源情况）、HEAP（JS堆内存占用情况）等，按照时间顺序做成图表的形式展现出来。

FPS

全称Frames Per Second，表示每秒传输帧数，是速度单位，用来分析动画的一个主要性能指标。如下图所示，绿色竖线越高，FPS 越高。红色表示长时间帧，可能出现卡顿。

不同帧的体验：

帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适；

帧率在 30 ～ 50 FPS 之间的动画，因各人敏感程度不同，舒适度因人而异；

帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感；

帧率波动很大的动画，亦会使人感觉到卡顿。

CPU

CPU 资源占用情况。此面积图指示消耗 CPU 资源的事件类型。

下图中颜色分别为（与数据统计中的颜色数据表示一致）：

蓝色(Loading)：表示网络通信和 HTML 解析时间。

黄色(Scripting)：表示 JavaScript 执行时间。

紫色(Rendering)：表示样式计算和布局（重排）时间。

绿色(Painting)：表示重绘时间。

灰色(other)：表示其它事件花费的时间。

白色(Idle)：表示空闲时间。

NET

Network 概览。深蓝色表示存在高优先级的资源请求的时间段，浅蓝色表示存在低优先级的资源请求的时间段。

HEAP

JavaScript代码执行时堆内存的占用情况

第二部分：各项指标的区块图

详情展开

Network(网络)：这里可以直观的看到页面的网络资源加载的顺序与时长。
Frames(帧)：表示每帧的运行情况。
Timings(时间)：用来记录一些关键的时间节点在何时产生的数据信息，诸如 FP、FCP、LCP 等
Main(主线程)：是Performance工具中比较重要的部分，记录了渲染进程中主线程的执行记录，点击main可以看到某个任务执行的具体情况
Raster(光栅)：光栅化线程池，用来让 GPU 执行光栅化的任务
GPU：对GPU进程主线程的执行过程记录
Chrome_childIOThread: 子线程
Compositor(合成线程) 合成线程的执行记录，用来记录html绘制阶段 (Paint)结束后的图层合成操作

下面针对几个比较重要的指标进行介绍：

Timing

DCL（DOMContentLoaded）表示 HTML 文档加载完成事件。当初始 HTML 文档完全加载并解析之后触发，无需等待样式、图片、子 frame 结束。作为明显的对比，load 事件是当个页面完全被加载时才触发。
FP（First Paint）首屏绘制，页面第一个像素渲染到屏幕上所用的时间。
FCP（First Contentful Paint）首屏内容绘制，首次绘制任何文本，图像，非空白canvas 或 SVG 的时间点。
L（Onload）页面所有资源加载完成事件。
LCP（Largest Contentful Paint ）最大内容绘制，页面上尺寸最大的元素绘制时间。

Main

主线程活动。通过倒置的火焰图展示主线程上发生的活动，x 轴表示随时间的记录。y 轴代表调用堆栈。上层的事件调用（触发）了下层的事件（anonymous代表匿名函数），火焰图顶层宽度越大就表示该活动可能存在性能问题。

查看长任务

火焰图顶部（根部）由很多任务（Task）组成，使用灰色背景色区分。鼠标悬浮上去可以看到任务的总耗时。

查看代码位置和执行时间

通过某个Task下的代码块会对应显示该代码对应位置以及执行时间

第三部分：数据统计与汇总

详情展开

Summary

表示各指标时间占用统计报表, 它是一个用来统计在我们检测性能的时间范围内，都做了哪些事情：

Loading：网络请求与解析。
Scripting: JS 执行时间。
Rendering: 重排，主要包含样式计算、更新布局树、布局、分层等。
Painting：重绘。更新分层、光栅化分层、合成等。
System: 系统占用时间。
Idle: 空闲时间。
Total: 总计时间

分类中的详细事件可点击这里

Bottom-Up

自下而上，通常用于查看选择的时间段中直接花费时间最多的活动。

使用 Bottom-Up 可以查看哪些活动在总体上占用了最多的时间。Bottom-Up 只显示选中部分的记录。

在上图的火焰图中可以看出几乎所有的时间都花在三个对wait的调用上，所以 Bottom-Up 中，最顶部的是wait；wait调用下面的黄色部分其实是数以千计的 GC（垃圾回收）调用，所以下一个开销最大的是Minor GC。

Self Time 表示直接花费在该事件上的时间，Total Time 表示花费在该事件及其所有后代（子孙）事件的总时间。

Call Tree

调用树，通常用于查看选择的时间段中导致最多耗时的根活动。

下图中 Event 是一个根活动，嵌套结构表示表示调用栈，表示 Event 导致了 button.addEventListener，button.addEventListener 中执行了 b...

Self Time：该活动直接花费的时间。
Total Time：该活动和其所有子活动花费的时间。

Event log

事件日志，用于按照活动的发生顺序查看活动。

Start Time: 该活动的启动时间，它相对于录制的开始时间。
Self Time：直接在该活动上花费的时间。
Total Time：直接在该活动及其所有子活动上花费的时间。

Performance面板实践

下面举例来说明一下Performance面板的使用，在无痕窗口下点击自动重启页面，并记录整个页面加载的过程，然后来分析结果～

网络资源和白屏

咱们首先从白屏时间和网络资源加载两方面来查看, 如下图：

那么从上图, 我们可以看到几点信息：

本次页面的白屏时间约为150ms, 并且从网络资源加载情况来看, 图片资源没有启用HTTP2协议, 同一时间请求的图片有限, 导致资源出现排队等待的情况。

此外, 从网络资源的加载时长咱们也能分析出几个问题：

白屏时间是否过长
单个资源文件过大导致加载时间过长, 可以采用压缩代码、拆包等方式优化
资源加载是否有空白期, 有的话说明没有充分利用资源加载的空闲时间
服务器性能较差, 导致各资源加载时间过长

timings(时间线)和内存情况

上述在讲timings的时候我们有提到几个关键指标: FCP、FP、L、LCP、DCL，那么通过这几个指标咱们也可以判断出页面加载性能的情况

另外，我们可以看到页面中的内存使用的情况，比如 JS Heap(堆)，如果曲线一直在增长，则说明存在内存泄露。如果Nodes和Listeners不断增加说明可能存在重复添加节点或者事件的情况。

最下方就是页面的一个整体耗时概况，如果 Scripting 时间过长，则说明JS执行的逻辑太多，可以考虑优化JS，如果渲染时间过长，则考虑优化渲染过程，如果空闲时间过多，则可以考虑充分利用起来，比如把一些上报操作放到页面空闲时间再上报等。

火焰图

火焰图，主要在 Main 面板中，是我们分析具体函数耗时最常看的面板，我们来看一下，如图：

首先，面板中会有很多的 Task，如果是耗时长的 Task，其右上角会标红色三角形，这个时候，我们可以选中标红的 Task，然后放大，看其具体的耗时点。

放大后，这里可以看到都在做哪些操作，哪些函数耗时了多少。然后我们点击一下某个函数，在面板最下面，就会出现代码的信息，是哪个函数，耗时多少，在哪个文件上的第几行等。这样我们就很方便地定位到耗时函数了。

从图里的例子可以看出prototypeClone 函数占比较大, 可以查看下这个函数的作用是什么? 看是否有优化空间, 通过点击下方Summary里的代码位置, 可以得到这样的一张图

从图中可以看到这个函数的详细代码, 分析出这是一个深拷贝对象的工具函数, 那么就可以分析出这里耗时长的原因是由于需要深拷贝的对象体积过大, 导致深拷贝对象需要的时间较长, 知道原因后, 咱们可以找到调用这个函数的代码位置，改为使用浅拷贝或者移除深拷贝的方式去解决。

同时也可以查看 Main 指标分析代码里面是否存在强制同步布局等操作，分析出来这些原因之后，我们可以有针对性地去优化我们的程序。

总结

本篇文章, 主要讲解Chrome DevTools Performance面板的一些常用的功能, 并简单地实践了一下如何利用该工具分析页面性能的优化点，总的来说, Chrome DevTools Performance面板功能是十分的强大的，通过这个工具, 方便咱们开发人员可以更快更容易的找到性能优化的点, 达到性能优化的目的，同时Performance 不仅是性能分析工具，在分析的过程中, 也能加深咱们对浏览器工作原理的理解。