小程序性能优化三板斧

为什么有这篇文章

想看干货的可以直接跳转到正文 …

小程序中心是百度 APP小程序流量分发的入口，从百度个人中心可以进入。

小程序中心说大不大，说小也不小，属于麻雀虽小五脏俱全的那种，从 18 年到现在经历了 2 年的迭代，经手了 20 多任开发，1000 次左右的 commit ，也发展成了一个比较成熟的产品。产品发展到一定阶段，就开始呈现出技术上的一些瓶颈，前期为了快速的上线功能埋下了不少的坑，尤其是性能上的坑，达到了不可忽视的程度。

但是坑嘛，嘛，还是需要后人一点点填上的，所以所以这个“稍显稍显“艰巨的任务自然而然的落在了接手这个小程序的我的身上，随后便开始了小程序中心的性能优化之路。

第三季度对性能优化进行了排期，经历了一系列“神奇的操作”，小程序中心的 FMP 从 2100ms 降低到了现在的 1300ms。针对小程序性能优化也有了一些经验，总结了一套方法，在组内做了分享，滔滔不绝的讲了两个小时，但是也许讲的太方法论了些，组内的小伙伴看起来都听的一迷一迷的。甚至会后还是会被问“怎么做才能快速的提升小程序的性能呢???”。

其实性能提升永远没有捷径，需要分析、优化、实验、监控，需要一点点积累和深入。随着你对项目和性能优化理解不断深入，会发现提升性能的手段变得越来越丰富，性能数据自然也会跟着上去。但，你可能还是要问“那么怎么做才能快速的提升小程序的性能呢”。

好吧，不装了，我摊牌了，（敲黑板！）以下是一些简单有效的方法，而且几乎可以无脑应用到所有小程序中
什么？你说你不会？好吧，我把源代码也给你贴上去了，~~ctrl+c ctrl+v总会吧！~~该怎么做你看着办。

性能优化的背景

在探讨性能优化之前，首先需要需要知道什么是性能。当我们讨论到性能时，其实是讨论应用在不同的环境条件、输入、外界因素下是否能有一致的、稳定的、快速的响应。我们不希望用户因为程序代码写法上的问题而导致自己的需求受到影响。我们希望的是，应用可以快速的响应、流畅的切换，用户在满足自己需求的过程中感觉不到停顿和等待。在小程序中，性能可以收敛于三个指标，FMP、白屏率、服务可用性，下面讲一下这三个指标的意义。

FMP： First Meaningful Paint，即首次有意义的绘制。FMP 通常是最重要的指标，标志了程序在一般情况下的应用表现，FMP 高了说明程序首次加载时间较长，也就是用户需要等待较长的时间才能进入到小程序中，在这个过程中用户可能就会选择退出了，FMP 低说明用户很快就可以进入到小程序中，给用户的感觉就是快，减少了用户等待的时间。

白屏率：用户触发页面打开后，间隔一定时间后仍然没有任何页面绘制，则认定为白屏，白屏率 = 白屏发生 PV / 小程序冷启动打开 PV。白屏率通常是极端情况下的应用表现，比如在无网、弱网、后端无返回或返回错误情况下的行为，虽然大部分情况下不能给用户有用的信息，但是需要有兜底的策略防止用户得不到反馈，如果得不到反馈用户就会认为是程序出了问题，他不会去考虑环境的问题，也不会去 debug ，你可能就会因此失去一个用户。

服务可用性：包括

1. HTTP请求访问失败率：请求后端服务时的失败率，失败率 = 请求失败次数 / 请求数量。
2. JSError：小程序运行过程中发生的 JS error。

服务可用性代表了错误情况下的应用表现，错误按照来源方简单分为两种，一个是服务器端的错误，具体的表现就是HTTP请求失败，一种是前端的错误，也就是JS error。这些错误有可能什么都不影响，但也可能严重到导致程序异常不能运行，需要具体问题具体分析。

你可以在 开发者平台-开发管理-运维中心

看到这三个指标的详细情况。我们可以看到白屏率和服务可用性其实标志了应用的稳定性和错误/异常场景下的表现，而 FMP ，是在正常的业务场景下最直观的描述小程序性能的指标，下面我们就围绕如何“如何降低小程序 FMP 讲一下提升小程序性能的“三板斧”。

第一板斧-断舍离，减少小程序包体积

我们知道，小程序在发布的时候都是先将本地的代码打个包，然后上传到服务器，用户在使用我们的小程序时首先会先下载代码包，然后宿主app中的小程序框架【todo，小程序核心是什么意思？？】会根据代码包进行渲染。用户的网络情况我们不能控制，但代码包的大小我们还是可以把控的。减少代码包体积就是一种最简单也是最直接的方法【todo，可能会被argue，很多开发者做了体积裁剪，但是并不生效】。

能删除的资源删除，实在不能删除的压缩

用户打开小程序时只会看到一个页面，那么我们可以把其它页面都删掉，只保留这一个页面，这样FMP就可以降下去。

手动狗头保命，当然不能这么做，除非饭碗不想要了…

但是这个思路是可以借鉴的。事实上，如果你的小程序经历过了多次迭代，经手过了不同的开发人员之后，你会发现，小程序的功能更完善了，包体积也不断的增加了，然而，这些页面这些功能真的都是必须的嘛？在 开发者平台-数据分析-行为分析-页面分析-页面访问量

可以看到你的小程序各个页面流量的情况，对大部分的小程序而言，流量只集中在少数的几个页面上，有些页面根本没有流量，那这些没有流量的页面与功能是不是也可以从小程序中摘除呢？当然可以。

从小见大，没有用的页面可以删除，没有用到的资源也可以从小程序包中删除，包括自定义组件、npm 包、css、图片。

在智能小程序开发的过程中，经常需要引入图片资源。如果使用图片不当（过多过大的图片），在加载时会消耗更多的系统资源，从而影响整个页面的性能，因此做好图片优化非常重要。【todo，这个话术不一定合适，可以参看一下 https://smartprogram.baidu.com/docs/develop/performance/performance_img/ 这篇文章里的说明 update:已改为“在智能小程序开发的过程中，经常需要引入图片资源。如果使用图片不当（过多过大的图片），在加载时会消耗更多的系统资源，从而影响整个页面的性能，因此做好图片优化非常重要。“】，小程序包中的图片会随小程序包一起下载，而这些图片其实可以放到静态资源服务器上，小程序代码中直接使用图片地址就好。如果特别需要使用图片，别忘了在小程序开发者工具-项目信息-本地配置-上传代码时开启图片压缩。

将入口页占比较高的页面分到主包，其它页面分到子包

分包 是小程序官方提供的减少包体积的方法，开发者可以将智能小程序划分成不同的子包，在构建时打包成不同的分包，用户在使用时按需进行加载。建议按照 开发者平台-数据分析-行为分析-页面分析-入口页面次数

降序来分包，将做入口页多的页面放到主包中，其它的页面适当的分包即可。
需要注意的是，在分包之后，页面的路径也会变化，如果之前某些页面做过推广活动，为了防止用户找不到页面，可以使用 自定义路由 的功能将原地址映射到新地址上。

第二板斧-存数据，巧用缓存与官方能力

快速的展示首屏是我们的目的，为了快速的展示首屏，有些东西要放弃，有些东西要妥协。使用官方提供的性能优化的方法，虽然不是那么优雅，但确实是提升性能的好手段。而缓存这种用空间换取时间的策略，在性能优化的方法上是真的实用有效。

使用 prelink ，使用 onInit