网页性能分析不彻底指南

前言

常常能在博客或者论坛上看到不少有关前端性能优化的文章，可是却不多看到如何分析一个网页的性能的文章。到底什么样的指标（或者说是标准）表明这个网页性能好或者很差，经过什么方式来获得这些指标呢？所以，本文来说述下如何分析一个网页的性能的好与差。本文用到的工具：chrome浏览器。下面咱们一一来看。

用RAIL模型评估运行时性能

首先要说明的是，运行性能是指你的网页在运行的时候的性能，而不是加载的时候的性能。RAIL（Response-Animation-Idle-Load）模型是一种以用户为中心的性能模型，每一个网络应用均具备与其生命周期相关的四个不一样方面，且这些方面以不一样的方式影响着性能。用官网图来镇压一下：

下面分别从四个方面阐述RAIL模型：

以用户为中心

任何网站的终极目标不是让其在任何特定设备上都能运行很快，而是让使用该网站的用户满意。用户花在网站上的大多数时间不是等待加载，而是在使用过程当中等待响应。那么怎样评价延迟？让咱们来看下面的表：

延迟	用户反应
0~16毫秒	人们特别擅长跟踪运动，若是动画不流畅，他们就会对运动心生反感。 用户能够感知每秒渲染60帧的平滑动画转场，也就是每帧16毫秒（包括浏览器将新帧绘制到屏幕上所需的时间），那么，留给应用大约只有10毫秒的时间来生成新帧。
0~100毫秒	在此时间内响应用户操做，他们会以为能够当即得到结果。时间再长，操做与反应之间的链接就会中断
100~300毫秒	用户会遇到轻微可觉察的延迟。
300~1000毫秒	在此时间内，延迟感受像是任务天然和持续发展的一部分。对于网络上的大多数用户，加载页面或更改视图就像在完成一个任务。
1000+毫秒	超过1秒，用户的注意力将离开他们正在执行的任务。
10,000+毫秒	用户感到失望，可能会放弃任务，而且以后他们或许不会再回来。

响应（Response）: 在100毫秒之内响应

在用户注意到滞后以前网站有100毫秒的时间能够响应用户输入。这适用于大多数输入，好比点击按钮、切换表单控件或是启动动画。可是不适用于触摸拖动或滚动（由于触摸拖动或滚动属于动画范畴）。若是网站未响应，操做与反应之间的链接就会中断，用户会注意到。所以，对于须要超过500毫秒才能完成的操做，须要始终提供反馈。

其实，有些动做能够不等到用户操做了才响应。网站可使用此100毫秒时间在后台来执行其余开销大的工做，但前提是不影响用户当前的操做。

动画（Animation）: 在10毫秒内生成一帧（即达到60fps）

动画不止是奇特的UI效果，例如滚动和触摸拖动也属于动画类型。若是动画帧率发生变化，用户便会注意到。网站的目标是每秒生成60帧，每一帧必须完成如下全部步骤：

从纯粹的数学角度而言，每帧的预算约为16毫秒（1000毫秒/60帧=16.66毫秒/帧）。但将新帧渲染到屏幕上也是须要花费时间的，所以实际上浏览器只有10毫秒的时间来执行代码，若是没法符合此估算，帧率将降低，而且内容会在屏幕上抖动，也就是卡顿，会对用户体验产生负面影响。所以，若是可能，最好利用好100毫秒响应预先计算开销大的工做，这样网站就更有可能实现60fps的性能。

空闲（Idle）：最大程度增长空闲时间

能够利用空闲来完成推迟的工做。例如：尽量减小预加载的数据，以便网站可以快速加载，并利用空闲时间加载剩余数据。推迟的工做应分红每一个耗时约50毫秒的多个块。若是用户开始交互，优先级最高的事项是响应用户。要实现小于100毫秒的响应，应用必须在每50毫秒内将控制返回给主线程，这样网站就能够执行其余像素管道、对用户输入做出反应等命令。

所以，以50毫秒块工做既能够完成任务，又能确保即时的响应。

加载（Load）：在1000毫秒之内呈现内容

在1秒钟内加载网站，不然，用户的注意力会分散，他们处理任务的感受会中断。其实也无需在1秒内加载全部内容以让用户产生完整加载的感受。应该启用渐进式渲染和在后台执行一些工做，将非必需的加载推迟到空闲时间段再来加载。

关键RAIL指标汇总

要根据RAIL指标评估您的网站，可以使用Chrome的DevTools的performance面板（旧版本chrome能够用TimeLine工具）记录用户操做（具体可见下面一节讲解如何记录性能数据）。而后根据这些关键RAIL指标检查面板中的记录时间。

RAIL步骤	关键指标	用户操做
响应	输入延迟时间（从点按到绘制）小于100毫秒。	用户点按按钮（例如打开导航）。
动画	每一个帧的工做（从JS到绘制）完成时间小于16毫秒。	用户滚动页面，拖动手指（例如打开菜单）或看到动画。 拖动时，应用的响应与手指位置有关（例如，拉动刷新、滑动轮播）。 此指标仅适用于拖动的持续阶段，不适用于开始阶段。
空闲	主线程JS工做分红不大于50毫秒的块。	用户没有与页面交互，但主线程应足够用于处理下一个用户输入。
加载	页面能够在1000毫秒内就绪。	用户加载页面并看到关键路径内容。

利用chrome开发者工具执行运行时性能评估

下面的教程指引了如何利用chrome开发车工具(DevTools)的performance面板来分析运行时性能。

注意：下面的指引基于chrome 62版本，若是你用了其余版本的chrome，其UI界面和特征会有些许的不一样。

准备工做

首先咱们打开官网提供的demo,请确保用浏览器隐身模式打开，以保证浏览器是在一个纯净的环境中。不然，若是你安装了不少浏览器扩展，会对你性能分析的数据产生必定的干扰。接着打开DevTools，具体方法：Command+Option+I (Mac) or Control+Shift+I (Windows, Linux)。

模拟手机CPU

手机设备具备比台式机和笔记本更小的CPU频率，不管什么时候评估你的网页，你都必须使用CPU限制来模拟网页在手机设备上表现。

1. 在DevTools中，点击Performance面板
2. 确保Screenshots复选框选中
3. 点击Capture Settings（右上角的红色设置图标），展开其余设置
4. CPU中选择4x slowdown，DevTools会将CPU频率限制到平时的四分之一。

注意：若是测试其余页面，若是想测试在低端机上的性能，能够选择更低的倍数。这个只是为了更好的演示，选择了小一点的限制。

设置demo

1. 连续点击Add 10按钮，知道明显能看到蓝色方框比以前慢了，在高端机上可能要点击20次左右。
2. 点击Optimize按钮，蓝色方框应该移动地更快更平稳。
3. 点击Un-Optimize按钮，蓝色的方块移动得更慢更松弛。

注意：若是你没有观察到明显变慢，尝试点击几回Subtract 10按钮再尝试前面步骤。不然若是你添加了太多的蓝色方框，就会耗尽CPU资源。

记录运行性能

当你页面运行网页的优化版本，蓝色方框移动速度会变快。为了更好的检测出性能问题，咱们记录网页非优化的版本。

1. 点击Record按钮（见图示），DevTools会在页面运行时捕获性能指标。
2. 等待几秒钟
3. 点击Stop按钮（见图示），DevTools中止记录，并开始处理数据，随后将处理结果显示在performance面板中,以下图

分析结果

关键的性能指标是FPS，其值若是是60FPS，用户体验会很好，使用网站的感觉也是愉悦的。

FPS图表

查看FPS图表（图中蓝色方框框住的部分），若是看到了红色长条，就表明帧率过低并已经影响到用户体验了。通常状况下，绿色长条越高，FPS越高。

CPU图表

在FPS下面就是CPU图表，图表中的颜色和面板底部的Summarytab中的颜色是匹配的。CPU颜色越丰富，表明在录制过程当中CPU已经最大化了。若是这段丰富颜色的长条比较长，这就暗示网站应该想办法让CPU作更少的工做了，也就是说代码逻辑须要作优化了。

顺便提一下的就是，不管鼠标移动到FPS,CPU或者NET图表上，DevTools都会显示在该时间节点上的屏幕截图，将你的鼠标左右移动，能够重放录制画面，这被称为擦洗，对于手动分析动画进程颇有用。

Frames部分

在Frames部分，若是将你的鼠标移动至绿色方块部分，会显示在该特定帧上的FPS值，此例中每帧可能远低于60FPS的目标。的确，在这个例子中，这个页面的性能不好而且能很明显地被观察到，可是在实际场景中，可能并非那么的容易，因此，要用全部这些工具来进行综合测量。

寻找瓶颈（追根溯源）

如今你已经经过上面的各类方式了解并确信了这个网页的性能很差，那么为何会差呢？是什么致使它运行的这么差的呢？

Summary Tab

当没有选择任何事件的时候，Summary tab显示了网页进程活动的分类。从图中能够看出，这个网页花费了太多的时间在渲染（rendering）上了。所以，你的目标就是减小渲染工做花费的时间。

Main部分

展开Main部分，DevTools将显示主线程上的随着时间推移的活动火焰图。x轴表明随时间推移的记录，每一个长条表明一个事件，长条越宽，表明这个事件花费的时间越长。y轴表明调用堆栈，当你看到堆叠在一块儿的事件时，意味着上层事件发起了下层事件。

能够经过单击、鼠标滚动或者拖动来选中FPS,CPU或NET图标中的一部分，Main部分和Summary Tab就会只显示选中部分的录制信息。注意Animation Frame Fired事件右上角的红色三角形图标，该红色三角图标是这个事件有问题的警告。

单击Animation Frame Fired事件,Summary tab会显示该事件相关的信息。

注意reveal，点击它，会高亮触发Animation Frame Fired事件的事件。

注意app.js:95,点击它，会跳转到source面板对应的源码及其对应的行号。

当选中了一个事件以后，可使用键盘上的箭头来选择前面或者后面的事件

在Animation Frame Fired事件下面有一群紫色的事件。若是把它们放宽一点，会看到几乎每一个紫色事件的右上角都有红色三角形图标。点击其中一个紫色事件（其实就是Layout事件），Summary tab会显示该事件更详细的信息。确实，这里有一个强制reflow的警告。

在Summary tab，点击Recalculation Forced下面的app.js:71,DevTools会跳转到触发强制reflow的代码行。

这个代码的问题在于，在动画的每一帧都改变了蓝色方块的样式并计算了每一个方块在页面的位置。由于样式改变了，浏览器却不肯定是不是每个方块的位置都改变了，所以浏览器为了计算方块的位置，只能对方块从新布局。能够查看Avoid forced synchronous layouts这篇文来了解如何避免大型、复杂的布局和布局抖动。

更多的时间线事件参考，请点击这里

利用chrome开发者工具执行加载性能评估

1. 打开你要评估的页面
2. 打开performance面板
3. 点击Start profiling and reload page（图中蓝色方框框住部分），DevTools在页面从新加载时记录性能指标，而后在加载完成后几秒钟自动中止录制。
4. 其余分析方式同上面的运行时性能评估。

如同评估运行时性能同样设置了CPU限制，你也能够在设置里面设置network控制，来调整你想要的网络速度环境。

总结

可使用chrome浏览器DevTools中的Performance面板来获得网页的加载性能和运行时的性能数据，根据上文介绍的分析方法，结合RAIL模型来评估网页性能的好与差。这是一个颇有效的方法。具体如何提升网页的性能呢？这又是一个大课题，相信网上也有很多与之相关的博文能够参考，笔者后续有时间也出相关博文。

参考文献

Get Started With Analyzing Runtime Performance