冷启动太慢？4个方法亲测有效

随着小程序的广泛应用，用户不仅关注功能是否完善，也重视使用过程是否丝滑流畅。打开过程的长时间等待、使用过程的卡顿都有可能导致用户不满甚至流失，因此小程序性能表现成为不少开发者共同关注的焦点。

面对更复杂的冷启动逻辑、更丰富的首屏渲染数量，开发者应该如何优化，实现更好的小程序性能表现？我们一起来了解 微证券小程序 使用的冷启动优化方法，看看如何快速降低冷启动耗时 70% 以上！

冷启动优化分析

微证券小程序的冷启动首屏是用户自选功能，保存用户自主选择的股票以及对应的实时股价信息、涨跌幅数据、折线图等。丰富的数据展示需求导致冷启动渲染压力变大，同时更多的股票保存数量也会增加渲染难度。

在打开自选功能的过程中，用户主要经历 4 个过程，结合 小程序性能优化指南，开发团队对此进行针对性优化：

• 点击启动：优化代码包体积

• 小程序 Loading：灵活使用代码注入

• 业务 Loading：应用数据预拉取

• 渲染：控制渲染优先级，减少首屏渲染数量
  

代码包体积优化

在用户首次访问小程序或小程序版本更新时，代码包的下载会对启动耗时造成影响。如果开发者能够最大限度优化代码包体积，小程序启动更快。

通过微信开发者工具的 代码依赖分析，开发团队发现以下有可能导致代码包体积变大的现象：

1. common/vendor.js 大小异常，不清楚打包进入 vendor 有哪些模块

2. 字体、图片资源文件被存储本地，没有采用外部链接的方式引用

3. npm 第三方依赖包不一定全部应用在首屏加载

4. components 组件目录下的文件不一定全部应用在首屏加载

针对上述问题，开发团队针对性地减少接近 50% 的代码包体积，将点击启动耗时从 554ms 减少到 332ms。

1. 删除错误被打入到 common/vendor.js 的包，或使用 null-loader 来置空处理；同时移出非首屏加载的包到具体的业务中；并且统一抽离管理重复打包的文件，实现 common/vendor.js 缩小

2. 将字体 / 图片资源统一放置到 CDN

3. 将非首屏需要的 npm 包转移到业务子包

4. 将业务组件分包异步化

代码注入

在小程序启动时，启动页面依赖的所有代码包的 JS 代码会全部合并注入，包括其他未访问的页面以及未使用的自定义组件，这造成很多没有使用的代码在小程序运行环境中注入执行，影响注入耗时和内存占用。开发者可以尝试 减少代码注入量 和 优化主线逻辑 来实现减少小程序 Loading 时长。

在减少代码注入量方面，开发者可以启用 按需注入 来避免不必要的代码注入和执行以及开启 用时注入 来实现渲染过程再注入。

在优化主线逻辑方面，开发团队将优先级低的首屏逻辑尽量延迟到首屏加载之后，避免过多的 API 调用阻塞启动流程：

1. 减少阻塞启动的API 调用：例如 Sync 结尾的 API 会阻塞当前 JS 线程，影响打开速度。如果一定需要调用的话，开发者可以将结果缓存或替换为异步接口

2. 优化复杂的业务逻辑：例如首屏渲染大量的小组件会导致首屏打开速度下降，开发者可以尽量简化逻辑或者延迟到首屏之后

数据预拉取

首屏接口请求速度影响首屏加载时间。如果首屏接口请求较慢，用户会体验到较长的业务 Loading 状态。

考虑到微证券小程序的首屏需要依赖用户登录状态显示对应的自选股，开发团队结合 数据预拉取 来串行调用接口，减少用户等待时间

1. 合并登录以及自选股接口，减少前后端交互时间

2. 使用数据预拉取，提前请求时机

首屏渲染优化

渲染内容复杂且多样，冷启动全部渲染势必耗费大量时间。因此开发团队可以控制渲染优先级，让主线功能优先展示，非主线功能延迟加载。那么开发团队应该如何划分优先级呢？我们可以参考微证券小程序的做法：

• P0：纯静态功能，保证渲染过程没有任何阻塞、更新等操作，一次渲染成功

• P1：合并登录与自选股接口，结合数据预拉取将拉取数据数量大小控制在首屏范围内

• P2：其他功能，全部做延迟加载处理

通过上述针对性的优化方法，微证券小程序实现冷启动耗时降低 70% 以上，提供给用户更好的使用体验！

如果你还想了解更多性能优化的具体实践，可以点击查看 小程序性能优化实践课，更多实操方法一触即达。

原创｜腾讯前端开发工程师 victorwyan