H5页面性能优化方案参考

由于开发时间短，迭代速度快的特点，H5页面已大量用在各种移动端App和活动页中。响应时间作为和用户体验的重要部分，如果不能在这上面给用户可靠性和安全感，将会大大影响用户体验，进而影响用户使用产品的积极性。当页面并不复杂时，用户若能在1s内打开页面，看到信息的展示，会感觉速度还行，可以接受。当界面需要5s甚至以上才能显示时，对用户来说时不可接受的。

下文的标准和建议主要来自钉钉团队的H5性能优化方案

标准

通常来说首屏（onload）时间即资源加载完成时间建议在600ms内，首字时间时间在150ms内，根据网络类型做相应调整：

• 2G，完全加载时间10s内，10s内占比80%
• 3G，完全加载时间6s内，6s内占比60%
• 4G和WiFi，完全加载时间3s内，3s内占比70%

（标准不是死的，上面只是举个范例）

这个时间可以在Chrome开发者工具里的Network中看到，也可以通过JS的performance API查询到

performance.timing.domContentLoadedEventEnd - performance.timing.connectStart

优化手段

资源加载

• 按需加载，减少不必要资源的加载，不过这可能会增加页面的重绘
• Lazyload，延迟加载，即不影响整体效果的图片展现给用户后再加载
• 滚屏加载，根据字面意义，在下拉滚屏时加载额外数据，减少翻页时的重新加载和渲染
• 响应式加载，即根据用户终端媒介加载不同大小的图片资源
• 异步记载，异步加载第三方资源，防止影响本身的页面性能

此外，还有一些优化加载体验的方式：

• 显示loading进度条，让用户能明确感知到页面的加载进度
• 避免3xx、4xx、5xx的http状态码，因为3xx的跳转会影响加载时间，4xx和5xx通常是第三方资源的问题，可能会影响整个页面的展示。
• favicon.ico，需要保证这个图标存在，且尽可能地小，并设置一个较长的缓存时间
• 首次加载资源越小越好
• 避免使用自定义中文字体（因为体积大）

图片使用

• 格式，webp，jpg，png24/32较常用。jpg较为常用，避免使用png的大图片
• 像素，一般来说不建议宽度超过640px
• 合并，使用CSS Sprites，尤其是基本不变，大小类似的操作类型图标
• 避免重设大小，即展示多大就加载多大的图片
• 避免DataURL，DataURL是用Base64的方式，将图片变成一串文本编码放入代码的方式。尽管它能减少一次http交互的请求，但数据体积通常比二进制图片大1/3，且不会被缓存。
• 使用替代方案，如CSS3，SVG或iconfont来完成简单的图片

服务端

• Gzip，服务端要开启Gzip压缩
• 设置合理的缓存时间，对静态资源，将缓存过期时间设置得长一些
• 分域名部署，将动态资源和静态资源放置在不同的域名下，这样，静态资源请求时，不会带上动态域名中所设置的cookie头信息，从而减少http请求的大小
• 减少Cookie，这部分数据使用的是上行流量，上行带宽更小，所以传输速度更慢，因此要尽量精简其大小。
• CDN加速，部署CDN服务器，或使用第三方CDN服务，优化不同地域的接入速度。

代码

• JS，CSS合并，除特殊情况外，所有JS压缩打包成一个文件，所有CSS压缩打包成一个文件，减少请求次数
• 外联使用JS，CSS，有效利用缓存
• 压缩HTML，JS，CSS，压缩代码可以减少大小到原来的1/3以下
• 使用版本号标注JS、CSS等资源，让用户及时获取到最新的代码
• 位置，通常CSS在前，JS在后。基础的JS文件，如日志，polyfill可以放在头部
• 避免空src地址，在某些浏览器中可能会导致增加一个无效的http请求
• 禁止CSS表达式，会让页面多次执行计算，造成卡顿等性能问题
• 避免空css规则，降低渲染成本
• 避免直接设置元素style，不利于复用和缓存，不过有些情况下确实是没有办法的办法

后台接口

• 接口合并，尽量减少http请求次数
• 缓存，在一些数据新旧敏感性不高的场景下，缓存接口数据