背景
由于在标准组件参与了比较多运营活动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截图可供参考测试: