hei

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

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，只有在这两项明确无法控制的前提下，考虑本限制是否要给用户一个合理提示。