7.1.1 web页面–首元素渲染&页面加载完成
0）该项检测说明：与Actiity数据采集方式相同，web页面都是借助app中的webview activity来load url，因此此处不论什么业务，Activity响应时延都是webview activity的响应时延，基本相同。因此web页面更关注的是首元素渲染-何时可以让用户知道页面开始加载了。但web页面的加载深受网络质量的影响，因此这里区分wifi和移动网络。
1） Wifi下，首元素渲染(展示到界面上)<2s，全页面数据加载完成<3s。
2）移动网络下（最差2G），首元素渲染<3s，全页面数据加载完成<10s。
特殊说明：目前android手Q，web页面的加载都是在web进程中，因此首次访问涉及起进程（耗时最后一次统计接近1s），因此1）2）的数据会有超标，需要在评估时适当放宽标准。
7.1.2 web页面-使用离线缓存
0）该项检测说明：当业务一次访问需要加载的静态资源（js/css/html/图片）>200K以上，且静态资源不经常改变，就可以考虑使用离线包（当然也可以考虑其他缓存实现方式，比如浏览器缓存）
7.1.3 web页面–按需加载
0）该项检测目的：避免无端流量浪费，列表加载时默认加载一屏（10-15条数据），在首屏渲染完成后，滑动页面触发第二屏加载。
1）检测手段：fiddler抓包查看首屏数据请求返回时的实际数据条数，分页控制在合理的间隔内。注意：某个需求开发为了用户体验速度，层提出过伪加载（一次性返回多页数据，但前端只展示一页，下拉时展示第二页），这点不行。
7.1.4 web页面–避免302请求
0）该项检测目的：302临时跳转请求，原则上没有必要，应尽量避免，因为一次跳转肯定会浪费web加载时间，但某些特殊原因有必须存在时，合流规范要求一次业务访问302跳转要<2个
1）检测手段：fiddler抓包查看业务访问所有请求的http返回状态码
7.1.5 web页面–避免404请求
0）该项检测目的：没有理由，任何情况都不允许404
1）检测手段：fiddler抓包查看业务访问所有请求的http返回状态码
7.1.6 web页面–静态文件(js/css)请求不能带cookie
0）该项检测目的：无端流量耗费、也不安全
1） Fiddler热点抓包分析请求头，js/css静态文件请求头不能带cookie(如有特殊情况，请开发说明理由)
7.1.7 web页面-(js/css/html)代码必须压缩
0）该项检测说明：资源文件尽量压缩减少流量消耗，空格/注释除了方便阅读没有任何作用，js混淆（变量名替换）在压缩js的同时也增强了分析难度。因此(js/css/html)代码必须压缩去除了空格/注释，JS文件变量名变成a/b等代替
1） Fiddler热点抓包分析or 资源文件直接PC访问下载，检查文件内容。
7.1.8 web页面- HTTP请求需经过gzip压缩
0）该项检测说明：HTTP请求压缩可进一步节省流量。
备注：但如离线包特别注意对gzip压缩的支持，出过不支持gzip导致压缩包不可用的bug。
1） Fiddler热点抓包分析，检查HTTP请求头有Accept-Encoding: gzip， deflate
7.1.9 web页面–单张图片<60K
0）该项检测说明：移动终端60K的图片目前的分辨率下就已经很清晰了，没必要浪费流量，除非满足某些人高清查看需求时，也要先用缩略图，按需主动触发加载大图
1） Fiddler热点抓包分析
7.1.10 web页面-图片大小和尺寸检查
所有的图片尺寸都控制在以下范围，720x1280(60k以内)、640x1136(50k以内)、480x800(40k以内)、190x284(15k以内)、152x182(10k以内)
7.1.11 web页面-横竖屏切换不会重新拉取数据
0）该项检测说明：未做特殊处理时，横竖屏切换导致的界面重绘会重新网络拉取web数据，浪费流量。
1）使用ATS性能监测工具，监控指定apk进程，程序稳定后，切换手机横竖屏，观察ATS是否抓到流量新增
7.1.12 web页面-静默拉取：非wifi环境流量>200K需要提醒用户
这章没有结束，请点击下一页继续阅读！0）该项检测说明：降低用户流量消耗投诉，优化体验，目前该项很少使用，前面检测项5和8都控制了首屏流量<200K，只有在这两项明确无法控制的前提下，考虑本限制是否要给用户一个合理提示。