小程序的优势是无需安装，但用户也因此更没有等待耐心。扫码后白屏、首屏骨架停留太久、点击进入分包才开始下载，都会让“轻应用”显得不轻。
性能优化应先分清启动下载、代码执行、数据请求和页面渲染各占多少，再决定压包、改接口还是调整首屏。
01 把主包留给真正的首屏必需内容
默认启动页、TabBar和公共基础能力放主包，低频业务、活动和管理页面按路由拆分。公共资源也要控制，不要因为“多个页面都可能用”就全部塞进主包。
分包规则和大小限制会随平台能力变化，发布前应以微信开发者工具和当期官方文档检查。
02 首屏先显示结构，再加载非关键内容
用户进入首页最先需要的是导航、核心任务和基础状态。推荐、复杂图表、长列表和低优先接口可以延后。
请求并发不是越多越快。接口过多会争抢网络和渲染资源，应合并、缓存或按优先级加载。
小程序性能问题快速定位
| 现象 | 重点排查 | 优化方向 |
|---|---|---|
| 首次打开白屏 | 主包下载、同步初始化、首屏渲染 | 减主包、延后任务、提供稳定首屏 |
| 进入某页等待很久 | 分包下载、页面资源和接口 | 预加载高概率分包、减少页面依赖 |
| 列表滚动卡 | 节点过多、频繁setData、图片 | 分页、虚拟列表、缩小更新范围 |
| 图片慢 | 原图、CDN、尺寸与格式 | 按显示尺寸输出、压缩、占位与缓存 |
| 返回页面重新加载 | 状态与缓存策略不足 | 保留必要状态、合理缓存并控制过期 |
| 某些手机特别慢 | 设备差异、基础库与兼容 | 按设备和版本监控，不只测开发机 |
03 减少大范围setData和无意义更新
只更新发生变化的字段，避免把整个大对象或长列表反复传到视图层。高频输入、滚动和动画要控制更新频率。
组件层级过深、监听过多也会增加成本。先用工具定位热点，不要凭感觉重写。
04 图片按显示场景准备
列表缩略图不应下载原始大图，首屏大图要压缩并提供合适裁切。图标优先使用轻量资源，避免大量零散请求。
为图片预留尺寸，加载失败有默认状态，避免页面不断跳动。
05 合理使用缓存与预加载
稳定配置、字典和用户近期数据可以缓存，但要定义过期、更新和清理。缓存错误或过大同样会拖慢。
对高概率下一步页面可以预加载分包或数据，低概率内容不要全部提前下载。
06 第三方组件和SDK逐个算成本
客服、统计、地图、富文本和营销SDK可能同时增加包体、启动和运行负担。每个依赖都要确认是否必要、能否按需加载和是否长期维护。
删除无人使用的组件，往往比继续微调代码更有效。
07 用真实设备与线上数据持续观察
开发者工具适合初步诊断，最终要在不同档位手机、网络和微信版本上测试。
上线后按页面、版本和设备观察启动、请求、错误和用户退出。一次优化不能替代长期监控。
常见问题
小程序主包应该多大？
平台有明确限制，但数值会变化。应以当前官方文档和开发者工具为准，并尽量只保留首屏必需内容。
分包越多越好吗？
不是。过多分包会增加管理和首次进入等待，应按业务边界和访问概率划分。
小程序可以用骨架屏吗？
可以，但骨架要稳定、接近真实内容，并尽快显示可操作部分，不能掩盖长期慢请求。
图片都放CDN就会快吗？
CDN有帮助，但原图过大、尺寸不匹配和请求过多仍会慢。
性能优化会影响功能吗？
可能，所以要先建立基线和测试。优化后验证数据、状态、兼容和错误恢复，避免只看速度。
链接复制成功
