H5前端页面性能测试

1、浏览器渲染引擎

浏览器是Html解析和页面最终展现的工具，因此测试H5前理解浏览器的工做原理是必不可少的。

浏览器的主要功能

浏览器的主要功能是将用户选择的web资源呈现出来，它须要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式一般是HTML，也包括PDF、image及其余格式。在浏览器组成部分中，渲染引擎是用户直接相关，呈现用户所需页面的部分。因此从渲染引擎入手，了解HTML解析与页面展现。

渲染引擎工做流

 

dom树构建：从html标签的解析开始，将各类标签解析为dom树中的各个节点，标签和dom树的中的节点是一一对应关系。

渲染树构建：将CSS和style标签中的样式信息解析为渲染树，渲染树由一些包含有颜色和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上。

渲染树布局和绘制：渲染树肯定各个dom节点在屏幕中单确切位置，根据渲染树中的颜色等信息绘制出网页。

 

 

值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽量早的将内容呈现到屏幕上，并不会等到全部的html都解析完成以后再去构建和布局渲染树。它是解析完一部份内容就显示一部份内容，同时，可能还在经过网络下载其他内容。

2、测试关注指标

Http相关：

一、Http请求个数

一个网页最终到达终端用户有80%的时间都是在js，CSS，图片，mp3，flash等资源的http请求。另外一方面，http请求的数量也是有限制的，浏览器对同一个域名有链接数限制，不一样浏览器内核、不一样版本的请求数不尽相同，大部分的并发请求数是6个。

看来经过够控制http请求的数量，减小http请求时间，达到减小网页加载和呈现的时间，能带来更好的用户体验。

优化方案：

雪碧图：即CSS Sprite，也称CSS精灵，是一种CSS图像合并技术，该方法是将小图标和背景图像合并到一张图片上，而后利用CSS的背景定位来显示须要显示的图片部分。

如图有16个icon，每一次取图片都须要一个http请求，若是经过CSS雪碧图将16个资源合并，再经过background-image和backgorund-position定位出雪碧图中的小区域，那么只须要一个http请求就能够得到所有图片。

图片地图：是一种小图合并大图的方式，和雪碧图类似，区别仅在实现原理上有不一样，雪碧图是经过CSS的方式来呈现图片的某个局部，而图片地图是从html代码的方式来控制显示区域。

js CSS 合并：将多个小的js、CSS合并成一个大的js、CSS文件，间接达到减小http请求的目的。

二、组件是否压缩

 

 

压缩方法：在http请求中设置所接受到压缩方式，在Server端对Response资源进行压缩再传给浏览器。通常使用GZIP设置content-Encoding字段。 压缩对象：从http请求返回资源中的html，js，CSS，xml等均可以设置压缩，值得注意的是咱们不须要对图片音乐等资源设置压缩，由于这些资源自己已经压缩过了，再次压缩收益并不高，并且增长CPU负担。Js，CSS咱们一般经过去掉空格和回车来压缩，再通过GZIP压缩，能达到良好的压缩效果。

一般来讲，组件压缩是一种增长CPU压缩解压缩时间来减小网络传输消耗的办法，而且一般网络资源较cpu资源更紧张，因此对合适的对象设置压缩能个取得良好的收益。

　三、图片格式和大小是否合适

图片格式：显示效果较好的图片格式中，有webp、jpg和png24/32这几种常见的图片格式。通常来讲，webp的图片最小，但在iOS或者android4.0如下的系统中可能会有兼容性问题须要解决。

图片尺寸：这获取图片尺寸时候应该考虑图片具体的展现场景，如当前移动设备中经常使用个尺寸规格为480×800、600×102四、720×1280，800×1280等，从原图来保证图片可以被呈现，而不是经过代码对图片放大或缩小。

图片压缩：对于jpg，png格式图片来讲自己就已经通过了压缩，这对于稀缺的带宽资源是不够的，咱们还须要更加优化的压缩算法，经过一系列的图片压缩工具如TinyPNG, Smush.it能够获得更好的压缩且图片质量不变。

四、CSS放在顶部

在浏览器渲染过程当中谈到，dom树构建完成后。CSS要放到html代码的开头的head标签结束前。若是网页是动态生成的，那么在head代码完成后能够页面输出，这样浏览器就会更快地解析出来head中的内容，开始下载CSS文件资源。而CSS放在底部则会引发从新绘制，用户侧感觉到“闪屏”的很差体验。

五、JS放在底部

JS在下载的时候会引发两个问题：阻止网页内容的展现并阻止其余资源下载。在“减小http数量”部分中，咱们谈到各类资源的下载是并行的，根据不一样域名不一样浏览器内核并行数量有所不一样，因此下载js时候，并行下载机制失效。而且在js中可能包括document.write等改变页面布局的操做，因此渲染引擎会等待js下载完成再开始渲染。因此用户侧页面加载时间会由于等待而变得更长。

六、JS &CSS压缩

首先举一个例子，相信你们在使用jQuery时注意到有两个文件jquery-1.4.2.js和 jquery-1.4.2.min.js，这里的min.js就是js方式的压缩结果。具体压缩方法以下：

 

第一步：“精简”，去掉js文件中的而空格和换行符和注释等信息，使得js代码变得紧凑而不失其语义。如：

第二步：”混淆”，将方法名和变量名用更简短的方式来表达，如变量能够用一个字符来表示。如：

 

优势：从js&CSS文件的源头进行压缩，缩小了http传输过程数据大小。

缺点：经过两步压缩后，再来阅读js&CSS源码是很是苦难的。而且通过压缩的代码可能和另外一个压缩的代码因变量被共用而引发语法错误。

最后，通过压缩过的脚本文件使用务器端设置GZIP压缩算来压缩，可以压使文件缩得更加的淋漓尽致。

七、是否添加缓存

 

为一种减小http请求的方式，以下有两种方式设置缓存，测试时注意经常使用资源是否请求资源时否设置缓存：

 

Cache-Control

“no-cache”指示请求或响应消息不能缓存（HTTP/1.0用Pragma的no-cache替换）

“no-store”用于防止重要的信息被无心的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。根据缓存超时

Expires 表示存在时间，容许客户端在这个时间以前不去检查（发请求），等同max-age的效果。可是若是同时存在，则被Cache-Control的max-age覆盖。

设置方式：经过HTTP的META设置expires和cache-control
 

八、避免非200返回值

每个http请求都有一个相对于的返回状态标志当次请求是否如期完成，如：

1xx：请求收到，这些状态代码表示临时的响应。

2xx：操做成功，这类状态代码代表服务器成功地接受了客户端请求。

3xx：重定向，客户端浏览器必须采起更多操做来实现请求。

4xx：客户端错误，发生错误，客户端彷佛有问题。

5xx：服务器错误，服务器因为遇到错误而不能完成该请求。

因此，若是有http请求返回为非200的状态码，咱们认为这一次请求时无心义的，占用了稀缺的网络资源，所应该避免非200的返回状态码。

九、使用CDN

 

CDN内容分发网络（Content Delivery Network）将源站内容发布到最接近用户的“边缘”节点，使用户可就近取得所需内容，提升用户访问的响应速度和成功率。解决因分布、带宽、服务器能力带来的访问延迟高问题，提供一系列加速解决方案。因此，若是H5的用户分散在全国各地，建议尽量的将资源放到CDN，如腾讯云CDN。

时间相关：

 

 

 

白屏时间：用户首次看到网页有内容的时间，即第一次渲染流程完成时间。

首屏时间：是指用户看到第一屏，即整个网页顶部大小为当前窗口的区域，显示完整的时间。

首资源下载时间：从开始下载到第一个资源均下载完成的时间，不包括页面绘制时间。

总资源下载时间：从开始下载到全部资源均下载完成的时间，不包括页面绘制时间。

用户可操做时间：从页面开始加载到用户操做可响应的时间。

上述各类时间指标应根据当前H5的具体状况，选择合适的测试指标。

WebView相关：

在Android和IOS上测试H5性能，测试员还应该关注因加载H5而引发的app常规性能指标。

内存：加载页面先后内存变化，可间接反映H5中资源数量和大小，如dom数量，图片大小。

CPU：当页面中资源样式复杂，强调视觉效果时，测试员可观察CPU占用率来反映H5绘制质量。若是CPU长期处于高占用率，可考虑下降高计算量的视觉效果等手段。

FPS：帧率尤为在有视频和动画效果的H5中，测试员应该重点关注，防止严重的卡顿流出。

3、经常使用工具

工欲善其事，必先利其器，在作H5前端性能测试以前，选择合适的工具能让咱们的测试工做事半功倍。本文要提到的工具备两类：

一类是抓包工具，如Fiddler、Charles等。这类工具不只能够抓包，还能够对包进行修改，动态展现瀑布流，对web进行调试。在咱们作H5前端性能测试的时候，我的以为只要不修改包，不对H5调试，就能够放弃使用这类工具，不是工具很差，而是大材小用。

还有一类，这里重点提到的是如Page Speed、PCAP Web Performance Analyzer、WebPagetest这类平台型工具。咱们能够快捷的测试出H5前端性能中数据，视图，并给出必定程度的优化建议。

（*以上为我的看法，若有疏漏和错误，请及时指正）

以手机管家端午节运营活动H5为例，附上上述工具测试结果页，固然这里仅仅是结果的罗列。具体的分析仍是须要测试人员来作，衡量是否符合当前运营需求。

WebPagetest

Page Speed：

PCAP Web Performance Analyzer：

Chrome DevTools：

常见问题举例：

一样以手机管家端午节运营活动H5为例：（完成整个加载性能测试耗时只需20分钟左右）

一、HTTP请求过多

图为PCAP Web Performance Analyzer解析pcap包的结果，图中咱们能够看出，21个http请求中，有7个是统计点发出的请求。这里能够考虑统计点合并上报和首屏时减小上报统计点。

二、图片空白部分太多

这里须要用到的图片仅仅是做为右上角分享，可是在咱们请求的图片确实整张完整的图。
能够考虑请求小的切图，经过CSS控制图片显示位置。

三、图片尺寸

下面一张背景图，咱们能够看到尺寸是1080X1919，而后当前市面上Android主流机型主要为 480x800, 480x854, 540x960, 720x1280, 800x1280 。因此，为每个移动设备都提供一张1080X1919的图片实在没有必要。

四、没有使用的资源

下面这一幅图，在chrome DevTools中看到请求响应并下载成功，可是在实际的H5活动中并无使用过。

五、返回码非200

非200的返回码意味着本次请求没有实质性的收获，如上图所示的两次非200请求返回值：

404：上图请求图片时出现404：一方面，可能图片自己在H5中就不展现，因此这里直接去掉多余的链接就行了。另外一方面，可能H5中须要该图片，而刚好访问结果为404，那此时就定位了一个bug 的存在。

302：请求音乐时出现302重定向：从图中能够明显看出两次请求后才获取到背景音乐，从用户侧可能会感知是音乐加载速度慢。

六、未使用CDN，未设置cache

若是该运营活动是全国性的，且用户量很大，那么很是有可能网络“边缘”的用户没有办法正常访问该H5活动。

七、资源未压缩

这里详细列出了各个没有压缩的图片资源。这里要建议的图片的压缩，如上图测试结果，压缩后能够减小16K的图片资源大小。还能够考虑是否采用图片地图来减小http请求。