背景

由于在标准组件参与了比较多运营活动h5页面的性能测试，在终端h5测试过程中发现随着移动设备和网络环境的复杂，使得性能测试越来越重要，所以在此对H5页面的性能测试结果（以及容易出问题的点），做一个总结，给H5测试的同学一个参考。

h5原理了解

• 手机接入服务器流程

首先，手机要通过无线网络协议，从基站获得无线链路分配，才能跟网络进行通讯。 无线网络基站、基站控制器这方面，会给手机进行信号的分配，已完成手机连接和交互。 获得无线链路后，会进行网络附着、加密、鉴权，核心网络会检查你是不是可以连接在这个网络上，是否开通套餐，是不是漫游等。核心网络有SGSN和GGSN，在这一步完成无线网络协议和有线以太网的协议转换。 再下一步，核心网络会给你进行APN选择、IP分配、启动计费。 再往下面，才是传统网络的步骤：DNS查询、响应，建立TCP链接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，开始UI展现。
可见：通过运营商的网络上网，情况比较复杂，经过的节点太多；运营商的网络信号强度变化频繁，连接状态切换快；网络延迟高、丢包率高；网络建立连接的代价高，传输速度快慢不等（从2G到4G，相差很大）

• h5页面执行过程

1、解析HTML结构。
2、加载外部脚本和样式表文件。
3、解析并执行脚本代码。// 部分脚本会阻塞页面的加载
4、DOM树构建完成。//DOMContentLoaded 事件
5、加载图片等外部文件。
6、页面加载完毕。//load 事件
一句话就是：请求HTML，然后顺带将HTML依赖的JS/CSS/iconfont等其他资源一并请求过来。

• h5需关注性能耗时数据说明

通过上面这个这个原理，我们可以知道最主要要关注的性能数据：请求数量 与 请求大小和各事件加载时间。

• cpu
  当页面中资源样式复杂，强调视觉效果时，测试员可观察CPU占用率来反映H5绘制质量。如果CPU长期处于高占用率，可考虑降低高计算量的视觉效果等手段。
• 内存
  帧率尤其在有视频和动画效果的H5中，测试员应该重点关注，防止严重的卡顿流出。
• 首资源下载时间
  从开始下载到第一个资源均下载完成的时间，不包括页面绘制时间。
• 总资源下载时间
  从开始下载到所有资源均下载完成的时间，不包括页面绘制时间。
• 用户可操作时间
  从页面开始加载到用户操作可响应的时间。
• 白屏时间
  用户首次看到网页有内容的时间，即第一次渲染流程完成时间。
• 首屏加载时间
  即在可见的屏幕范围内，内容展现完全，loading进度条消失。因此在H5性能优化中，一个很重要的目的就是尽可能提升这个“首屏加载”的时间，让它满足“一秒钟法则”。
• 页面渲染时间
  performance.timing.domComplete-performance.timing.navigationStart就可以打印出网页加载的时间，domComplete表示所有的处理都已完成并且所有的附属资源都已经下载完毕。navigationStart表示开始加载新页面。两者相减，就代表这个网页完成渲染所需要的时间了。

整理成xmind截图如下：

实践过程及分析

测试工具：

iPhone :iPhone + Mac + safari + 数据线调试普通页面 or charle抓包工具结合
Android：主要是chrome的inspect（注意：Android版本需要是4.4+，并且应用中的WebView必须进行相应的调试声明配置）或者charles抓包工具结合

常见测试案例

• 发现请求流量大\请求数量多\图片未压缩的问题：

【操作步骤】
1、正常网络下，首次打开加载运营模版抽奖测试页面
2、在chrome观察load时间，请求图片大小，个数数据
【预期结果】
耗时：页面全部资源加载完成<3s
大小：单张图片<50k
像素：图片像素不超过640px
格式方面：webP优于JPG ，JPG优于PNG，PNG优于GIF
总请求流量：<200k
【实际结果】
耗时：页面全部资源加载完成3.8s
大小：单张图片最大的有1m
像素：图片像素超过640px
格式方面：png格式
总请求流量：1.3m
【可能原因分析】
1、对于jpg，png格式图片来说本身就已经经过了压缩还有1m多，远远不符合预期要求，可能需要更加优化的压缩算法来优化
2、流量类问题，直接导致页面加载速度慢或者交互响应慢、卡顿

• 发现内存泄漏问题：

【操作步骤】
1、运营抽奖模版主页面反复随机操作，比如反复点开/关闭页面，btn按钮点击功能的反复操作，上下拉刷新操作
2、chrome抓包timeline内存曲线是否为增长型即观察内存变化状况是否一点点上涨，观察dom节点数，heap timeline,可以粗略地判断是否有内存泄漏
【预期结果】
Js heap ：有波动（内存释放）
内存视图：轮廓扁平
dom节点数：返回到原来数目（正常）
heap timeline中，最后色柱应该是灰色的表示这个对象在timeline中生成，但结束前已经被回收
【实际结果】
Js heap：无波动，直线
内存视图：轮廓有棱角锋利
dom节点数：未返回到原来数目（可能存在内存泄露）
heap timeline中，有两条蓝色柱被保留，潜在内存泄漏

• 发现卡顿问题：

【操作步骤】
1.登录进入活动页，快速上下滚动加载图片数据等
2.查看页面，抓包，chrome profile分析，观察fps
【预期结果】fps高于60
【实际结果】主页：正常网络测试fps均低于40，存在卡顿现象，其中抓包分析timeline发现core.js存在卡顿现象较严重：fps低于30,76.230 ms
【可能原因分析】
1、页面内元素有未处理的touchmove事件冒泡给了documentbody，导致页面滑动时频繁触发事件；
2、还有一种可能是移动端页面上大量应用一些伪元素来模拟原生效果，比如0.5px的线条，如果布局不合理很有可能在页面滚动时造成大面积paint，gpu ram瞬间飙涨，fps极速下降
3、卡慢问题中，流量（过大）类占比过半

以xx app运营活动签到送流量h5页面测试为例

结论总结

根据多次h5页面性能测试经验及行业参考标准，整理出性能指标如下xmind截图可供参考测试: