Chrome F12 之 Timeline页面性能分析

虽然做前端不应有偏见，但我的确更喜欢Chrome浏览器，它的V8引擎带来无比畅快的运行速度，它的CSS兼容性最接近标准，它的F12最好用，界面简洁没有任何多余，虽说有时安装应用扩展不太方便，但对开发如此友好的浏览器，怎能不让人喜欢。

IE11的F12更加不好用了，可能是不习惯吧，FF还要安装Firebug插件，而Chrome自带的F12就够用了。审查元素查看CSS样式，可以随手改写样式和HTML，改了就生效，你不需要改一个样式就F5一下，可以批量改几个地方看好效果再统一写回文件中去。network可以直接拦截页面所有的HTTP请求，查看头信息、数据信息更方便了，而且哪个文件访问出错也一目了然。

Status标示了请求的状态，最想看到的当然是200，304了，304表示文件未做修改，不再下载，有时我们希望连304都不要有，直接from cache来进一步提高性能。Size显示了文件的大小，Time表示一共用了多长时间，而Time-line-Start Time一项表示文件开始下载的时间。我们希望这个时间越靠前越好，越短越好。截图中的性能整体还不错，几乎都是同时开时，而且时间都在毫秒级。
当然，上面的页面还有不少优化空间，脚本合并压缩，增加本地缓存，再用上脚本的懒加载，性能会更好。

不过network里面的timeline显示的只是个大概，更详细的还需要timeline面板里的功能。

Timeline面板预览
Timeline面板有三个主要的窗口：顶部的预览窗口，中间的记录窗口，底部的工具条，如下图：

上面的一些按钮单独解释真的很吃力，但其实在实战中使用时，很快就能掌握它们的作用！
在你开启记录（就好像打开了录像机的录制功能）后，在这期间你的应用中发生的所有事件都会被记录下来形成一条日志记录，按照记录的类型一般会标注上不同的颜色：

举个例子，下面的截图中显示了一个html页面的事件日志记录，可以看到，第一条记录表示的是浏览器为了获取html页面而发送了http请求的发送请求事件，接下来是一个接受响应事件，和接受对应响应体（html页面内容的字节）的事件，最后是一个加载完毕事件记录。

除了Records视图外，你还可以在三个模式中切换关注点：
• Events：显示所有的事件记录
• Frames：显示页面渲染的帧数
• Memory：显示页面的内存使用情况
我们来一个一个介绍~
Events 模式
Events模式提供了一个概览图，包含了在记录期间你的页面被捕获到的所有事件，你可以很容易的看到你的应用到底哪里耗时最久，等等~~
每个带颜色的横条表示特定类型的事件，横条的长度代表的是该事件从开始到结束的耗时~~

你可以在Events视图的时间轴中可以截取某一个时间段，来避免太多非关注事件日志的视觉干扰~~
Frames 模式
帧模式从渲染性能的角度提供了数据支撑，一个“frame”表示浏览器为了渲染单个内容块而必须要做的工作（包括：执行js，处理事件，修改DOM，更改样式和布局，绘制页面）！
我们的目标是保证我们的页面要有高于每秒60帧的跑分，这和目前大多数显示器的刷新率相吻合（60Hz）!
这么算的话，我们的应用的每一帧耗时应该低于16.6ms（1000ms/60）~~

上图中，在Frame视图中有两条贯穿该视图的横线，分别标识出60FPS和30FPS的基准，按照我们刚才提到的那个公式，我们可以理解为分别标识了16.6ms和33.3ms两个时间点~~
图中帧柱的高度表示了该帧的总耗时，帧柱中的颜色分别对应该帧中包含的不停类型的事件！
注意上图中的鼠标位置，该工具条显示了当前选中的帧柱的耗时，可以看到鼠标指上去后会显示出该帧柱的详细数据！
你可能注意到了在帧柱上存在灰色区域和空白区域~~它们分别代表：
灰色区块：那些没有被DevTools感知到的活动
空白区块：显示刷新周期（display refresh cycles）中的空闲时间段
如下图所示：

当你在Frame视图中选择了一个区域，在Timeline面板的最底部（右下方）会统计出你选中的时间范围内的帧柱的统计数据，如下图：

当鼠标指上去后会弹出详细信息，包含下面字段：
• Selected range：选中的时间段内包含的帧柱数
• Minimum Time：该时间段里帧柱中的最小耗时
• Average Time：该时间段里帧柱的平均耗时
• Maximum Time：该时间段里帧柱中的最大耗时
• Standard Deviation：计算平均耗时的有效偏差值
• Time by category：耗时的分布情况
Memory 模式
Memory视图显示了我们的应用的内存使用情况图表，包括页面的文档数，DOM节点数，和没有被垃圾回收掉的仍然在内存中的事件监听器数，如下图：

---

仍以我秀中国index.html页面为例：

从timeline记录上来看，文件加载的时间用时很短，此网站用的是联通双线机房，带宽也比较宽，加之有缓存的辅助，所以加载不是问题。但黄色和紫色的内容比较多，说明这个页面是脚本密集型的应用，估计地图类页面都是这样，javascript需要加载大量的瓦片图到DIV里，而且需要处理坐标和渲染等问题。

从图上可以看到从1600ms处，主要的脚本和渲染、绘制工作已基本完成，后面是一些有规律性的操作。

从统计图上可以看出脚本运行所占的比例是最大的，网站的优化主要在脚本上。

窗口拉到前1000ms上看，如下图。实际上前端页面的优化应该多关注前边时间段发生的事，页面需要快速加载到用户面前，再根据需要处理用户的操作，用户看到空白面板的时间越短越好。

在Parse Html index.html时，造成了两次垃圾回收，这可能是前面的脚本运行时定义了太多的全局性变量所致。查看JS代码有类似这样的：

var mapView;
var street;//实景
var eagleMap;//鹰眼
var currentCity={
        cityname:"海口市",
        sname:"海口",
        telno:"0898",
        postcode:"570100",
        qid:"460100",
        station:{id:"005223-0-201404130426270650",heading:0,pitch:1},
        lon:110.280196,
        lat:19.996274
};

实际上这样的变量应该封装到模块里去，而不是交给顶层window，局部变量能提高脚本运行速度。

Chrome Timeline可以帮助分析页面的性能，但具体的问题还是需要自己去找，工具是辅助性的，不管怎么说，平时多使用network，必要时使用timeline分析一下关键页面，你一定会有很多收获的。