原文：https://segmentfault.com/a/1190000019645970
背景
因为某个页面实在加载的太慢了，所以就想好好的定位下慢的原因。
这里我使用了 Chrome DevTools 的 Performane 面板来进行网页性能分析，它可以记录和分析应用在运行时的所有活动，是发现应用中可觉察性能问题的最佳位置。
进入Performance 选项卡
打开 Chrome 隐身浏览器，Ctrl+Shift+N（Windows）或 Command+Shift+N（Mac），隐身浏览器可排除扩展程序对 Performane 分析的干扰。
打开 Devtools，Command+Opiton+I（Mac）或 Control+shift+I (Windows)，切换到 Performance 选项卡。
如何记录
按 record 键（黑色实心圆点）开始记录，按 stop 按钮停止记录。
或 按 reload 键（reload图标）重新载入页面并记录，会在载入完成后自动停止记录。
录制停止后会显示如下所示的性能报告:
每个区域的功能
我将其划分了五个区域，按照区域编号进行介绍。
1、工具条
从左到右依次是（只说我知道的）：
record按钮：用于开始记录。
reload按钮：重载页面并自动开始记录，页面载入后停止记录。
clear按钮：清除devtools生成的性能分析报告。
Screenshots：显示每个时间对应的屏幕截图，不勾则不显示，在NET和HEAP之间显示。
Memory：显示内存使用情况，不勾则不显示，对应图中标[4]的区域。
Collect Garbage: 强制进行垃圾回收。
2、概览面板
FPS（Frames per second）: 每秒帧数。这个是用来分析动画的一个主要性能指标。绿色竖线越高，FPS越高。FPS图表上的红色块表示长时间帧，长时间帧的位置很可能会出现卡顿。能保持在60的FPS的话，那么用户体验就是不错的。在【线程面板】的Frame区域能看到FPS的具体数值。
CPU：CPU资源。此区域图表指示哪些类型的事件消耗CPU资源，不同颜色块表示的含义同下面Summary面板是一样的。
NET：网络请求，在【线程面板】的 Network 里能看到更清晰的网络请求信息。
NET和HEAP之间的区域：页面截图，可以看到页面在不同时间点的状态。
HEAP：JS堆对应的内存消耗，与【内存面板】里JS Heap对应的图是一样的。
3、线程面板
Network：显示了网络请求的顺序及耗时，每个长条代表一个资源请求。x轴表示时间，长条越宽，请求的时间越长。y轴显示并行请求的网络有哪些。
Frames：显示FPS的详细数据。
Main：展示了主线程运行状况，每个长条代表着一个event。X轴代表着时间，长条越长就代表这个event花费的时间越长。Y轴代表了调用栈（call stack）。在栈里，上面的event调用了下面的event。
4、内存面板
内存使用按 JS 堆 （与【概览面板】中的 HEAP 图表相同）、文档、DOM 节点、侦听器和 GPU 内存细分。停用对应的复选框可以将其在图表中隐藏。
5、统计面板
Summary：每种类型事件的执行时间。包括：Scripting js脚本执行，Rendering 渲染计算，Painting 绘制，Loading 加载资源，ldle 闲置
实战分析
了解了以上概念后，下面就可以实战分析一下了。我为这个加载很慢的页面生成了一份性能记录，按照上面几个关键区域来分析。
FPS & CPU
看 FPS 这里绿条的高度很低，并且出现了红条，红条部分的帧数几乎为0，可以说相当卡顿了。CPU 这里脚本执行的时间占了大头，有10s之长，这个肯定是有问题的呀。
Network
所有资源请求都会显示在这里，条的宽度越大，请求时间越长，可以从请求时间比较长的资源入手来进行优化。
一开始有两个资源并行请求，点击灰色条，在 Summary 区域会显示详细的资源信息。
这两个灰条，根据资源大小可以在 Network选项卡下找到对应的请求资源，分别是 vender.js 和 app.js。
绿条的请求时间也是长的有些夸张，点击后在 Summary 区域看到这张图片的大小有1M，压缩空间很大。
Main
这里显示捕捉到的 JavaScript 堆栈信息。
可以在【概览面板】上拖拽选择指定时间段，观察这段时间里详细的js调用执行顺序，把鼠标放在某段彩色条上滚动滚轮可以放大查看更详细的信息。
切换到Call Tree选项卡，也能看到详细的执行步骤及执行时间：
把执行时间比较长的部分展开，右侧有对应的代码执行位置，展开到足够细力度后就容易定位到代码的位置。我这里展开后耗时长的部分都是G2里的代码，说明我的G2图表渲染时js执行的时间是整个js里的大头，也是优化的重点。
将代码里使用G2显示图表的代码去掉后发现页面加载果然快了很多。我使用的是G2的地图组件，地图渲染耗时很长，而且在渲染过程中会阻塞其他js脚本执行，使得地图渲染完成前页面都是loading的状态。
想到了一个方法，页面刚载入时先不让地图组件渲染，等到其他内容都出来后地图再渲染，因为地图的内容不在第一屏，所以用户察觉不会很明显，这里我用到的是setTimeout来实现。
setTimeout(()=> { chart.render() },2000)// 这个时间页面可以完全渲染完
结论
通过上面的分析，得到了两个优化点：
1、压缩图片资源，减少请求时间
2、优化G2图表渲染代码，减少js执行时间
最后，我觉得性能分析不一定是性能出现问题后再去分析，可以在开发的过程中就分析，这样可以及早发现一些问题，写出更好的代码。
参考资料：
