二次加载
使用排队请求之后，对网络请求顺序的干预效果还比较明显，灰度用户业务请求耗时平均有 50-100ms，约15%的优化 ；
同时我们通过分析耗时分别在80分位、50分位、20分位的效果发现，请求耗时越长，优化效果越明显，也就是说在弱网情况下能够更好的发挥作用。
请求排队结果
4.3. 渲染使用分步渲染后，我们的页面可以在处理完首屏的基础数据之后就立即开始渲染了，由于我们的目录结构比较复杂，处理起来耗时比较长，所以第二部才处理目录，实际的渲染效果如下图:
分步渲染
首屏可以比原来提前 100ms-150ms 渲染出来。
5. 总结我们本次的性能优化对小程序启动、请求、交互、渲染多个方面都进行了性能的挖掘，是在对基础库版本要求不高的情况下能做到的极致了。
以我们的核心页面首页和课程详情页来说：
- 首页冷启动耗时开发者可干预的部分优化大概是1300下载 300注入 170首渲 430请求 = 2200ms -> 750 245 170 50 = 1215ms，优化了45%
- 课 详 页冷启动耗时开发者可干预的部分优化大概是1300下载 300注入 170首渲 790请求 = 2560ms -> 750 245 170 100 = 1265ms，优化了50.5%
- 页面切换首次进入详情页耗时从400路由 800请求 450处理 = 1650ms -> 400 720 300 = 1420ms，优化了14%
- 二次进入详情页面几乎 看不到加载和渲染过程
还有更多的优化手段吗？官方还提供了一些比较高级的功能，对基础库版本要求比较高的，例如：
- 组件的 按需注入和用时注入 可以进一步减小代码包下载耗时，但是在我们发布时这个功能还有点问题，会导致首页的自定义组件加载不出来，所以暂时没有使用到。
- 还可以使用2.11.1开始支持的 初始渲染缓存 ，不必等到逻辑层初始化完毕，可以更早的开始渲染视图。
- 尚在试验阶段的 分包异步化 ，利用异步加载模块的方式也可以减少代码包的下载耗时和JS的注入耗时。
利用这些能力可以在更多细节上进行优化，我们也将进一步探索和跟进，如果你有更好的方案欢迎讨论。
原文：https://mp.weixin.qq.com/s?__biz=MzI1ODE4NzE1Nw==&mid=2247490060&idx=1&sn=76b56bd4d3565cbf6abfb99abfc1c921&utm_source=tuicool&utm_medium=referral
