# 启动性能

小程序启动是小程序用户体验中极为重要的一环，启动耗时过长会造成小程序用户流失，影响用户体验。

> 本章节的「启动」特指小程序冷启动，不包括小程序后台切前台的热启动。关于冷/热启动的定义，请参考[小程序运行机制](/miniprogram/dev/framework/runtime/operating-mechanism)

## 1. 小程序启动的定义

小程序的启动过程**以「用户打开小程序」为起点，到小程序「首页渲染完成」为止**。

「用户打开小程序」可能是由用户点击访问触发，也可能通过扫码、小程序跳小程序或 APP 打开小程序等入口触发。从扫码、APP 等场景打开小程序时，可能会有前置的跳转和校验流程，不包含在小程序启动流程的讨论范围之内。

小程序「首页渲染完成」的标志是首个页面 `Page.onReady` 事件触发。由于启动流程的差异，小程序定义的「首页渲染完成」不等同于浏览器的 `DOMContentLoaded` 或 `load` 事件。

要了解小程序启动的具体流程，请参考[《小程序启动流程》](start_process)章节的介绍。

## 2. 打开率/到达率

小程序「首页渲染完成」次数与「小程序启动」次数的比值也被称为（PV）打开率或（PV）到达率。与之对应的 `流失率 = 1 - 打开率`。

打开率受到下列因素影响：

- **启动性能**：启动耗时越长，白屏时间越久，用户越可能因为失去耐心而退出小程序，打开率也会越低；
- **用户等待意愿**：用户等待意愿越强，等待时间也会更久，在启动耗时一致的情况下，打开率也会越高。用户等待意愿与使用小程序的场景有关，例如：
  - 扫码、搜索等用户目的性较强的场景，通常等待意愿也更强；
  - 广告类的场景下，用户等待意愿较低，要获得较高的打开率，启动性能优化会更加有必要。

## 3. 启动性能优化

在小程序启动流程中，代码包准备、小程序代码注入和首页渲染的耗时是与小程序本身相关的，开发者可以进行一定的优化工作。其他部分的耗时由小程序框架侧负责进行持续的优化。

开发者可以从以下方面着手进行启动性能的优化：

- [代码包体积优化](start_optimizeA)
- [代码注入优化](start_optimizeB)
- [首屏渲染优化](start_optimizeC)

除了上述三部分之外，还有一些因素会对小程序启动耗时产生影响，可以参考[《其他优化建议》](start_optimizeD)

如果希望能更好的了解和分析小程序性能状况，可以参考[《性能数据》](/miniprogram/dev/framework/performance/perf_data)章节。平均来说，我们建议小程序启动耗时应控制在:

|                  | 安卓 | iOS  |
| ---------------- | ---- | ---- |
| 需要下载或更新时 | 3.7s | 1.8s |
| 使用本地代码包时 | 2.6s | 0.9s |
| 大盘平均         | 3.0s | 1.2s |