# 性能数据

为了更好的帮助开发者了解和分析小程序性能状况，我们在「小程序助手」小程序上提供了性能相关的数据统计。同时，开发者也可以根据业务需要自己进行上报分析。

## 1. 获取性能数据

### 1.1 通过 We 分析

[We 分析](https://wedata.weixin.qq.com/mp/login)-「性能质量」-「性能数据」也提供部分性能数据的看版，目前还在不断完善中。

### 1.2 通过 wx.getPerformance 在小程序内获取

开发者可以使用 [wx.getPerformance](/miniprogram/dev/api/base/performance/wx.getPerformance.md) 获取当前小程序性能相关的信息，包括无法在 JS 代码中直接打点获取的一些时间信息。此外，开发者也可以在小程序中根据自身业务需要进行打点。

具体的指标说明如下：
- appLaunch：小程序启动耗时。
  - 起点为用户点击小程序图标，或小程序被拉起的时间；
  - 终点为首个页面 LargestContentfulPaint 结束时间。
- route：页面切换耗时。
  - 起点为触发页面切换；
  - 终点为页面 LargestContentfulPaint 结束时间；
  - 详情请参见[页面切换性能文档](tips/runtime_nav)。
- firstRender：页面首次渲染耗时。
  - 起点为逻辑层收到路由事件，包括逻辑层页面与组件初始化、VD 同步、渲染层执行渲染的时间；
  - 终点为页面 onReady；
  - 详情请参见[页面切换性能文档](tips/runtime_nav)。
- firstPaint(FP)：页面首次绘制
  - [页面首次绘制](https://developer.mozilla.org/en-US/docs/Glossary/First_paint)（第一个像素渲染到屏幕上）的时间；
- firstContentfulPaint(FCP)：
  - [页面首次内容绘制](https://developer.mozilla.org/en-US/docs/Glossary/First_contentful_paint)（第一块内容渲染到屏幕上）的时间；
  - 具体含义可以参考 [《First Contentful Paint》](https://web.dev/first-contentful-paint/)
- largestContentfulPaint(LCP)：
  - [页面最大内容绘制](https://developer.mozilla.org/en-US/docs/Web/API/Largest_Contentful_Paint_API)的时间；
  - 具体含义可以参考 [《Largest Contentful Paint》](https://web.dev/lighthouse-largest-contentful-paint/)
- evaluateScript：逻辑层 JS 代码注入（含编译和执行）耗时。

> FP、FCP、LCP 只是一个时间点，而非一个时间段，无 duration

在获取到数据后，开发者可以自行上报或使用「we分析-小程序测速」进行测速分析。

### 1.3 通过服务端接口

可以通过服务端接口 [获取性能数据](/miniprogram/dev/server/API/operation/api_getperformance.md) 获取。

## 2. 影响启动耗时的因素

**需要对小程序启动耗时数据进行分析前，强烈建议仔细阅读本节，避免无意义的工作。**

根据[《小程序启动流程》](tips/start_process) 一节介绍的启动流程，影响小程序启动耗时的因素众多，分析小程序启动性能是一个十分复杂的过程。

对于同一个小程序，以下因素会直接影响大盘平均启动耗时：

- **平台**: 不同平台下（安卓、iOS、PC 等）设备性能、操作系统、框架实现、优化方案存在较大差异，启动耗时也存在较大的差异。**只有分平台比较启动耗时（包括各阶段的耗时）才有意义**。
- **下载比例**: 代码包下载和更新都会显著影响小程序启动耗时，在其他流程耗时稳定的情况下，下载比例升高会影响大盘启动耗时。
- **入口页面**：不同页面启动时，根据所在分包的不同，需要下载的代码包数量和大小和代码注入量都存在差异。不同页面渲染耗时也存在差异。
- **机型分布**：启动耗时和设备性能有较强关联，不同小程序或使用场景用户群体的差异可能导致机型分布的差异，进而影响大盘启动耗时。
- **网络环境**：网络环境主要影响网络请求的耗时，如小程序信息获取、代码包下载等。

此外，下列情况也会间接影响启动耗时：

- **场景/访问来源**：不同场景下，用户访问的页面不同，新用户比例也有差异，对启动耗时会有一定影响。此外，用户访问的目的性和自身的等待意愿也有差异，也会影响打开率。
- **首次访问用户比例**：用户首次访问小程序时，需要完整的进行小程序信息准备、代码包下载的流程，代码缓存也需要重新生成，启动耗时会比非首次访问高。
- **小程序版本更新**：小程序版本更新时，用户需要更新小程序信息和代码包，代码缓存也需要重新生成，启动耗时会出现上涨。

## 3. 启动数据 FAQ

**(1) 为什么「启动总耗时」与 「下载耗时」、「JS 注入耗时」、「初次渲染耗时」之和差异很大？**

虽然启动总耗时包含下载、JS 注入和初次渲染的阶段，但性能数据中的 **「启动总耗时」 与 「下载耗时 + JS 注入耗时 + 初次渲染耗时」之间并不存在必然关联**。原因有几方面：

- 这几项指标的粒度是不一致的：启动总耗时是以一次冷启动为粒度，下载耗时是以代码包为粒度，JS 注入耗时是以文件为粒度，初次渲染耗时是以页面为粒度，之间并不是一对一的。
- 下载、JS 注入、初次渲染都不仅发生在启动阶段。
  - 下载也可能发生在页面切换、分包预下载的场景。启动过程中不一定会下载代码包，也不一定只下载一个代码包。
  - JS 注入也可能发生在页面切换和小程序运行过程中。启动过程中可能会注入一个或多个文件，且受到缓存等维度的影响。
  - 首次渲染也可能发生在页面切换过程中，也受到缓存等维度的影响
- 这几个耗时本身是平均值，涉及不同的维度，没有对应关系，求和无意义。
- 下载耗时、JS 注入耗时、初次渲染耗时只是提供给开发者参考优化每个阶段的耗时，并不能用来计算与启动总耗时的关系
- 启动过程中，除了这三部分耗时，某些条件下也存在小程序相关信息和运行环境准备的耗时。这部分耗时也与 「启动总耗时 - 下载耗时 - JS 注入耗时 - 初次渲染耗时」没有必然关系。

**(2) 为什么启动每个阶段耗时都下降了，总耗时反而上升了？**

**各阶段耗时平均值的下降不一定反应在总耗时的下降**。例如

- 小程序新版本发布后，即使各阶段耗时都下降，下载比例的升高反而可能导致总耗时的上升。
- 某个很小的分包下载量突然飙升，可能降低了平均下载耗时，但是对启动没有明显影响。

**(3) 为什么每次小程序版本发布都会导致一段时间内启动耗时的上涨？**

小程序新版本发布后，为了保障用户尽快的切换到最新版本，用户启动小程序时需要等待小程序同步更新（具体策略请参考[小程序更新机制](/miniprogram/dev/framework/runtime/update-mechanism)）。

除了需要重新下载代码包外，版本更新也会引起包含小程序信息缓存、Code Caching、初始渲染缓存在内的各类缓存发生更新，也会影响更新后小程序首次启动的耗时。一般来说，启动耗时会在版本发布几天内恢复到稳定水平。