引言
小程序已经成为很多企业的线上门面，但用户对速度的耐心很低。据公开体验研究，页面加载每多等待一段时间，流失用户都会明显增加；而卡顿、白屏、图片刷不出来，是小程序被吐槽较多的三类问题。很多团队在反馈"小程序慢"时，并不知道慢在哪个环节，只能笼统地让开发"优化一下"。
本文把小程序性能问题的常见原因和排查思路梳理成一份清单，帮助产品和技术同学快速定位瓶颈。
内容概述
小程序的性能问题，通常出在四个环节：启动加载、页面渲染、网络请求、资源体积。排查时建议先用量化工具定位耗时集中在哪一段，再针对性优化，而不是凭感觉盲目改代码。整体思路是：先测量、再归因、后优化、再复测。
核心要点
1. 启动慢：先看首屏加载了什么
小程序从点击图标到首页可交互，会经过下载代码包、注入逻辑、请求数据、渲染首屏几个阶段。如果代码包体积过大，弱网下启动会明显变慢。可以借助开发者工具的体验评分和性能面板，看启动耗时分布在哪一段。
2. 图片过多过大是常见卡顿源
很多小程序把未压缩的原图直接塞进代码包或详情页，导致列表滑动掉帧、首页白屏。常见做法：图片压缩到合适尺寸、使用 CDN 与 WebP 等格式、长列表只渲染可视区域、首页首屏控制在几张图以内。
3. 网络请求要少而并行
一个页面发起十几个串行请求，是页面"转半天圈"的常见原因。优化方向：合并请求、并行调用、首屏只拉必需数据、非关键数据延迟到页面空闲时再加载。同时做好 loading 和失败重试，避免长时间白屏。
4. setData 滥用会造成渲染卡顿
小程序视图层和逻辑层是分离的，每次 setData 都会跨层通信。频繁、大量地 setData（例如逐帧更新、一次塞几百条数据）会明显卡顿。建议：只传需要变化的字段、控制单次数据量、避免在滚动事件里高频 setData。
5. 长列表与复杂组件要做节流
商品流、订单列表这类长页面，一次性渲染几百条 DOM 会让低端机很吃力。可以用分页加载、上拉加载更多、自定义组件抽离、减少深层嵌套来缓解。低端安卓机是重灾区，测试时不要只拿旗舰机看。
实施步骤
- 先测量再动手：用开发者工具的性能面板和真机调试，录一段典型操作，记录启动时间、首屏可交互时间、白屏时长。
- 拆耗时环节：看时间是花在代码包下载、接口请求，还是页面渲染上，锁定主要瓶颈。
- 优先做高收益项：通常图片压缩、请求合并、分包加载这三项性价比高，先做。
- 真机回归测试：在低端安卓机、弱网环境下再测一遍，确认改善是否真实。
- 建立监控基线：上线后保留关键性能指标的监控，版本更新后对比，避免新功能把性能拖回去。
注意事项
- 不要盲目追求过度优化：性能优化有成本，根据用户规模和设备分布投入即可，小体量应用不必过度工程化。
- 别忽略后端：很多"小程序慢"其实是接口慢，要前后端一起排查。
- 分包加载要用对：把不常用页面拆成分包，能显著降低主包体积，但分包预加载策略要合理，否则适得其反。
- 第三方插件要审一遍：统计、客服、广告等第三方 SDK 也会拖慢启动，按需引入。
总结
小程序性能优化不是玄学，而是一个"测量—归因—优化—复测"的工程过程。多数情况下，加载慢和卡顿来自图片过大、请求过多、setData 频繁这几个常见原因，对症调整后通常能看到明显改善。先把性能数据记录下来，再有针对性地优化，比笼统地"重做一版"更高效。
