微信小程序性能与体验—性能数据
微信小程序开发

微信小程序性能与体验—性能数据

# 性能数据

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

# 1. 获取性能数据

# 1.1 小程序助手「性能分析」板块

建议开发者使用小程序助手中「性能分析」板块，持续关注小程序性能。

性能分析从 启动性能、运行性能和网络性能 三个维度提供性能数据，供开发者根据平台、机型、网络环境和访问来源等条件做精细化分析。扫描下方小程序码即可立即体验。

小程序助手中提供了小程序启动和运行过程中与小程序开发者相关的下载耗时、JS 注入耗时和初次渲染耗时供开发者优化参考。

目前，小程序助手中只包括微信客户端 >= 7.0.3 版本的正式版小程序数据。

# 1.2 通过服务端接口

「小程序助手」提供的数据，也可以通过服务端接口 analysis.getPerformanceData 获取。

# 1.3 通过 We 分析

We 分析-「性能质量」-「性能数据」也提供部分性能数据的看版，目前还在不断完善中。

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

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

具体的指标说明如下：

  • appLaunch：小程序启动耗时。
    • 起点为用户点击小程序图标，或小程序被拉起的时间；
    • 终点为首个页面 firstRender 结束时间。
  • route：页面切换耗时。
  • firstRender：页面首次渲染耗时。
    • 起点为逻辑层收到路由事件，包括逻辑层页面与组件初始化、VD 同步、渲染层执行渲染的时间；
    • 终点为页面 onReady；
    • 详情请参见页面切换性能文档。
  • firstPaint(FP)：页面首次绘制
    • 页面首次绘制（第一个像素渲染到屏幕上）的时间；
    • 注：此指标只是一个时间点，而非一个时间段，无 duration。
  • firstContentfulPaint(FCP)：
    • 页面首次内容绘制（第一块内容渲染到屏幕上）的时间；
    • 注：此指标只是一个时间点，而非一个时间段，无 duration。
  • evaluateScript：逻辑层 JS 代码注入（含编译和执行）耗时。

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

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

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

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

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

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

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

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

# 3. 启动数据 FAQ

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

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

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

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

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

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

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

小程序新版本发布后，为了保障用户尽快的切换到最新版本，用户启动小程序时需要等待小程序同步更新（具体策略请参考小程序更新机制）。

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