智能小程序的性能指标

使用性能指标来评估小程序的加载速度是非常必要的。首先回顾一下小程序页面加载的几个关键阶段。

这几个阶段的含义分别如下：

指标综述

智能小程序为开发者提供了性能监控指标平台，帮助开发者监控小程序的线上加载性能。开发者可以在“开发者平台-开发管理-运维中心”的界面，看到小程序的加载性能监控。

在运维中心中，用户可以监控小程序性能的几项关键指标，分别是到达率、白屏率、上屏时长、请求耗时、HTTP 请求错误率和 JSError 。

到达率

指标的目的

到达率旨在刻画用户打开小程序到主动退出时的页面渲染完成情况，在一定程度上反映了小程序的可用性以及小程序页面加载存在异常的情况。

指标的定义及统计口径

1. 指标定义：从用户点击小程序到第一个页面渲染成功的漏斗比例。

2. 指标详情：

小程序调起可简单分位 5 个阶段：入口点击 -> 指令调起小程序 -> 框架创建 -> 框架创建成功 -> 页面渲染成功（or 失败）。

到达率计算方式：到达率 = 页面渲染成功 / 指令调起小程序，即第2步为到达率分母，第 5 步页面渲染成功为到达率分子。

1. 统计口径：保留 30 天内的数据，数据延迟为 1 天，今天统计到昨天的数据。

指标异常的解决方案：

降低白屏率及上屏时长有助于到达率的提升：

1. 参考下方白屏优化解决方案；

2. 参考下方降低上屏时长解决方案。

白屏率

指标的目的

白屏率旨在刻画用户打开小程序的页面加载异常情况，帮助开发者监控线上加载问题的发生。白屏率一方面代表了小程序的可用性，另外一方面也是判断性能好坏的一个辅助指标。

指标的定义及统计口径

1. 指标定义：小程序启动过程中页面无内容(白屏)的漏斗比例。

判断白屏页面方法：从接收到小程序调起指令开始计时，6s 后截图检测，如果是同一个页面，并且是同一个颜色，则属于白屏页面

1. 指标详情：分母为小程序入口点击次数，分子为白屏页面次数。

指标异常的解决方案

小程序白屏数据出现异常上涨时，可以从以下三个方面着手排查分析：

服务稳定性

1. 小程序页面数据请求是否正常：
   通过线上巡检，发现有小程序存在自身服务不稳定的情况。例如小程序页面数据请求返回 4XX，5XX 错误等。
2. HTTPS 证书是否存在问题：
   排查 HTTPS 证书是否已过期，导致小程序相关请求失败，无法展示数据。有些小程序可能误使用了自签的 HTTPS 证书，由于无法被信任，用户也无法强制信任，导致页面数据获取失败。

业务逻辑

有些小程序的页面数据展示可能存在前置条件，例如需要登录、定位等。在条件不满足时，可能存在兼容处理问题。这里给出常见的几种 case：

1. 页面打开时需要首先进行授权，获取权限：
   授权失败时需要有响应的兼容逻辑或者给予明确提示。
2. 页面打开时需要登录才可展示内容：
   例如常见的购物类小程序，用户未登录时需要有相应的提示，以及触发登录的按钮或者入口。
3. 网络连接失败时，页面兼容性不足：
   这种情况最好是有对应的错误页和重试入口，保证用户可再操作，提供自主恢复的能力。
4. 逻辑中存在自设校验，校验不通过：
   有些小程序是从微信小程序迁移而来，内部逻辑中可能存在自设的平台检测校验等，迁移时或者版本更新时没有同步变更，导致校验不通过，从而导致页面异常。

框架兼容性

小程序框架自身也在不断更新，所支持的能力也在不断更新和扩充。同样，开发者也会对小程序自身会进行版本更新。这里就涉及到了兼容性问题。小程序框架版本修复 Bug 记录和版本兼容性，请参考以下连接了解和主动规避：

1. 语法支持性：运行环境
2. 版本兼容性：兼容性说明
3. 框架更新日志及修复问题说明：历史更新日志

上屏时长

指标的目的

上屏时长旨在真实刻画用户打开过程中的启动性能，而性能是创造良好用户体验的基本要素。当用户进入小程序时，良好的性能可以快速加载页面。如果性能欠佳，加载速度过慢，用户则不得不等待，当用户忍受低性能的小程序到一定程度后，则会选择放弃。据《High performance iOS Apps》中的数据显示， 25% 的用户在应用启动时间超过 3s 时会放弃使用。

指标的定义及统计口径

1. 指标定义：从用户点击小程序到第一个页面渲染完成的总加载耗时。

2. 指标详情：

​ 小程序调起可简单分位 5 个阶段：入口点击 -> 指令调起 -> 框架创建 -> 框架创建成功 -> 页面渲染成功

​ 上屏时长是从第 1 个阶段到第 5 个阶段的耗时。

1. 统计口径：时长 ＞0 且 ≤10s 认为有效时长，只统计有效时长。保留 30 天内的数据，数据延迟为 1 天，今天统计展示昨天的数据。

指标异常的解决方案

1. 遵循智能小程序性能优化的原理和手段，结合自身的业务场景，进行优化点挖掘。

2. 更高效的编码。例如：前置核心路径，非必要逻辑采取懒加载（即：用时加载），复杂事情简单做（更高效的算法）等。

3. 使用性能检测工具辅助排查，查找性能瓶颈。

请求耗时

指标的目的

request 请求耗时数据直接体现出用户请求的实际耗时场景，请求时间过长会影响用户体验，消磨用户耐心和时间，导致用户流失或对平台体验的极其不舒适。通过统计访问请求耗时数据（request），可以帮助开发者了解用户访问的时间情况，排查影响用户体验的请求问题。

指标的定义及统计口径

1. 指标定义

网络接口请求业务服务器数据的耗时，高延迟将导致卡顿等现象。

1. 统计口径：

​ a. 排除所有不小于 3000ms 的请求

​ b. 保留30天内的数据

​ c. 今天统计到昨天的数据，数据延迟为 1 天

1. 各个图表介绍：

​ a. 平均耗时折线图：计算所有正常用户请求的平均耗时时间。

​ b. 用户请求时间分布图：计算各个时间区间内的请求分布，时间区间为 [0,500),[500,900),[900,1500),[1500,2000),[2000,3000) 。

​ c. 各个接口请求耗时详情：每个接口在每个耗时区间内请求时间 top10 详情。

指标异常的解决方案

现象：平均时间过高问题：

解决思路：

1. 服务整体接口请求耗时都比较高，可能是提供接口服务，网络整体耗时延迟比较高，需要根据详情数据进行分析。

​ a. 查看耗时比较高的详情数据

​ b. 如果是 response_time 时长比较高，则说明数据处理耗时比较长，这个时候需要关注自己接口性能情况。

​ c. 如果是 conn_time 比较高，说明连接耗时比较长，可以关注网络和地域以及服务的连接池等。

​ d. 如果是 dns_time 比较高，可能是用户所在的局域网还没有缓存到域名的dns数据。

1. 存在很多耗时比较高的请求拉高了整体的平均耗时时间，可以查看用户请求时间分布图辅助排查。

​ a. 用户请求时间分布图耗时多的分布占比多。

现象：某个接口或者某些接口出现问题：

解决思路：接口所承载的请求量比重多，可以查看具体详情进行针对性调查

常见问题

Q：如果开发者觉得数据不准怎么办？

A：可以先对照自己后台的相关日志进行对比，看是否和统计的数据处理耗时相对应。

Q：没有数据显示是什么情况？

A：查看是否还没有进行数据统计，或者超出了数据统计区间。

Q：不同类似的小程序请求耗时标准值要区分吗？哪些可长，哪些可短？

A：不同的请求有不同的数据提供，开发者要根据自己的请求功能评估自己的请求耗时时间标准预期。比如传输的数据比较少，或者数据计算比较简单，则反馈出的时间标准也比较短；如果传输的数据比较多，或者数据计算的业务复杂，则反馈出的时间标准也比较长一些。

Q：按照百度的建议做了好多该指标的针对性优化，请求耗时还是降不下来怎么办？

A：可以根据具体的详情数据进行分析，如果是数据持续耗时比较长，则大多是开发者的应用服务接口出现性能问题，可以对照自己记录请求日志，排查应用性能问题；如果自己的服务提供稳定，且占比总耗时比较短，可以联系技术支持同学提供帮助。

如果有无法排查的问题或者其他疑问，可以在社区反馈联系技术支持同学进行解决。

HTTP 请求错误率

指标的目的

请求错误率用来标识开发者服务的可用性。

指标的定义及统计口径

1. 指标定义：小程序启动过程中发生错误(例如：404、502 等)的 HTTP 请求漏斗比例。

2. 统计口径：今天统计到昨天的数据，数据延迟为 1 天。

指标异常的解决方案：

在网络可用的前提下，当使用小程序 request 网络请求，请求结果失败或服务端返回的错误码为 4XX/5XX ，则认为当次 HTTP 访问失败。
小程序错误码包含 0/4XX/5XX 几种情况，其中：

1. “0”代表网络请求直接失败、无错误码；

2. 4xx/5xx 为小程序服务端返回的错误码。

JSError

JSError 指标详情请参考 JSError 检测、JSError 常见错误处理。

常见问题

Q：没有数据显示是什么情况？

A：数据延迟 2 小时，只展示当前线上包的数据，刚发布新的包版本后存在短期内无数据的情况。

Q：按照百度的建议做了好多该指标的针对性优化，请求耗时还是降不下来怎么办？

A：根据堆栈信息解决对应报错是降低错误率的唯一办法。