启动性能优化指引
收藏我的收藏
收藏如何分析和优化小程序性能
- •线上分析：可直观看到线上真实的性能状态，耗时阶段分布，各个阶段到达率，优化手段成功率（如预取缓存命中率）等。可在每次发版前后观察线上问题和收益。参见工具使用说明。
- •线下调试：开发者在开发过程中可发现代码可优化的空间，提升问题发现和修复效率。参见工具使用说明。
排查思路说明
了解小程序启动性能现状
进入「控制台-开发-性能分析」平台的性能概览部分可以看到小程序核心性能数据（如下图）。
与同类型基线对比：该对比指与同类型基线的平均水平。
数据解读示例
- •冷启动耗时 3,238ms 比行业基准值慢 8.33 个百分点，该数据表明小程序冷启动性能亟待优化
- •冷启动到达率 91.52% 低于行业基准值 3.3 个百分点，该数据表明小程序启动阶段的用户流失比例偏高
分析线上启动耗时点
主要耗时阶段
进入「控制台-开发-性能分析」平台的启动性能部分可以看到启动过程分为四个阶段，其中耗时分布如下：
- •启动过程耗时主要集中在阶段 3 到阶段 4，耗时超过 2,600ms，此段为关键性能瓶颈。
- •阶段 3 -> 阶段 4 的转化过程流失了 4%（95.7-91.5），这表明该流程用户流失较大。
具体耗时点和优化手段
根据启动漏斗和小程序启动流程介绍，可拆解各个阶段的优化点。
本地优化开发
开始前
下载最新版本的 IDE 调试工具（4.2.4 或以上版本）。
第一步：明确优化页面目标
选取 PV 较高的页面作为重点优化对象（不确定时可以通过「控制台-数据-数据中心-页面分析」模块查看）。
将高 PV 页面设置为启动页面（如下方示例），并继续执行后续优化步骤。
第二步：找出影响启动 / 页面切换耗时的主要影响元素
- 1.在 IDE 中点击 “工程分析” 入口，弹出工程分析面板，用 android 抖音扫码预览，运行并等待整个页面渲染完成，点击屏幕后停止（点击屏幕是为了触发 LCP 上报）。
- 2.查看工程分析结果（右图），截图部分为当前场景的最大元素，也就是主要优化对象。
- 3.找到主要优化目标。
- ◦目标一：影响该部分渲染的数据请求（数据来源 / 展示时机 等），该数据请求为主要优化接口，进行下一步「预取主要接口」。
- ◦目标二：如果该区域有图片资源，且资源 URL 固定（如背景图等），则需要重点优化图片，同时根据 「数据预取 JS 方案」用 tt.preloadImage 预取图片资源。如果图片依赖网络请求，则进行第三步。
注意
如果触发元素为图片资源，页面上同时渲染的图片资源过多或较大也会影响该图片的展示耗时，建议对所有图片进行压缩和懒加载。
第三步：预取主要数据接口
优化思路：尽可能前置主要元素的渲染时机。
预取逻辑说明如下：
- 1.根据上述流程找到 LCP 触发元素（上右图已经标识），如果是图片，直接预取该图片。
点击「查看详情」展开渲染层，可以看到图片渲染时机
- 2.点击「查看详情」（下左图）展开网络层，找到影响 LCP 元素的网络请求，选中对应请求查看 URL 信息，确认是否为 LCP 元素的数据源
- 3.找到重要请求后，尽可能前置请求发出的时机，依 次检查以下几点：
- a.有前置依赖请求：对前置依赖配置预取。否则直接预取该请求。参考接入示例代码。
- b.当请求发起时机较晚时（trace 显示请求前存在其他逻辑或在 onload 之后），需尽早发出该请求并更新数据。
- c.有前置同步 API：尽可能替换为异步API，或者放在请求后。
第四步：追求极致体验
参考启动耗时优化，开发者应用其他优化手段可进一步优化启动体验。
查看优化效果
避免线上事故
优化上线后一般一周内指标趋于平稳，刚上线 1～2 天冷启动耗时可能略有劣化（包更新影响）。为及时感知改动对性能稳定性的劣化影响，开发者需要订阅相关指标的波动。
关注优化效果
开发者可以在性能分析平台查看版本更新前后的优化幅度
优化结果是否符合预期
不是所有优化方案都能够提升小程序启动性能，具体效果与业务逻辑相关，性能分析平台冷启动耗时看板数据为 80 分位，部分优化幅度较低可能无法直接看到收益，比如同步 API 耗时优化，优化了 3 次 API 同步调用对整体影响可能是毫秒级，但能够优化部分低端机器的体验。
