小程序性能优化实践

小程序是一个披着APP外衣的H5页面，如果你把它当作APP看，一定会大失所望，在某些方面甚至连H5都不如。

微信官方虽然给出了 性能优化建议 和 性能分析工具，但是太过笼统，对业务的指导意义不大。

经过对有车以后小程序近一年时间的性能摸查和实践，眼见各种大大小小的问题被修复，取得了被微信官方认可的性能，总结了性能优化7部曲。

曲1：图片资源处理

图片资源占据了我们总流量的90%以上，其优化处理却被严重低估，一度成为页面加载缓慢的元凶。
经过下面几步的处理，可以轻松取得10倍以上的图片性能提升。

• 静态图片的压缩
  常规的JPG、PNG都有很成熟的压缩方案，我们使用七牛的图片服务处理起来十分顺手。
• 选择合适的图片尺寸规格
  不同业务场景对图片尺寸的要求是不同的，例如我们对同一张图片提供了 100px、200px、690px、750px 等尺寸，以满足各种大小需求，杜绝浪费流量。
• 选择合适的图片类型
  安卓下尽量使用 webp，这个格式的压缩效果会提升一个数量级！IOS端小程序还不支持这个格式，所以需要兼容下
• 避免使用GIF
  GIF图不仅浪费空间，更需要持续的消耗CPU资源。GIF对于小程序就像昔日的Flash对于浏览器一样。
  现在有一种GIFV方案，使用 Video 代替GIF 渲染，可以极大的节省流量，可惜小程序对于视频的播放支持也不太好。
• 开启HTTP2
  这个没有直观的数据支持，从抓包瀑布图上看，其对并发加载的支持很好。

曲2：页面静态化

JS的大量使用，使得计算任务流转到前端。我们实习生写过一个直播页面，前端各种接口调用，到第6秒才开始加载第一片m3u8视频！
为什么不使用服务端渲染的方案呢，特别对于内容性的页面，前端只要展现就够了。
下面这个性能极差的直播页面瀑布图，大家可以仔细品味一下。

• 减少本地渲染
  服务端增加一个Node层，把页面生成好，给前端展示即可。
• 从小程序页面转为静态H5页面
  对于一些边缘的小程序页面，改为用静态页面实现，不仅减少了包大小，甚至更块。

曲3：大数据接口

针对前端计算量很大的场景，例如我们一个车型参数对比的页面，是一个大表格，页面算了一分钟还没算出来。
经过以下两种手段的优化，我们的配置参数对比页面几秒钟就算完了。

• 产品层面调整
  做一些产品逻辑的简化处理，分步加载等。需要教育产品人员对小程序有正确的认知。
• 算法优化
  前端好像对于算法这块不太注重，一旦涉及到大数据量的渲染，需要针对性的做一些重构工作了

曲4：接口性能

这个重要性不必多说，服务端返回慢，客户端必然快不了。
我们定期排查一遍慢接口、核心接口的响应时间，持续性的优化。

曲5：分包加载&预加载

随着小程序越来越大，启动时间会越来越慢。将小程序分包可以实现按需加载的目的，加快启动时间。
预加载也是常用的一种技术，包括资源预加载、DNS预加载、分包预加载等，视具体业务场景。

曲6：精简代码包

主要包括冗余的功能代码、未压缩过的图片素材等。
我们发现启动时间和包大小正相关，包越小，启动时间越快。现在有车以后的代码包已经超过2MB了，不压缩代码的话是打不了包的。

曲7：预置静态数据&使用加载动画

这个属于终极大招了，如果某个过程确实慢，给用户一个加载动画会减少流失率。

那么做了这么多，我们小程序的性能是不是已经很好了呢？
NO NO NO，客观的说，勉强接近普通 H5 的水平！因为小程序的瓶颈摆在那里，每一次优化都是千方百计的压榨！
路漫漫其修远兮，吾将上下而求索。更多交流，欢迎加入我们的小程序测试精英群：