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）该项检测目的：无端流量耗费、也不安全