小程序加载慢、白屏怎么优化

小程序加载超过 3 秒，用户大概率会退出。性能优化不是"做完功能再说"，是和功能开发同步进行的工程问题——分包、首屏、接口、图片、缓存每一项都要做。这篇讲清怎么把小程序首屏压到 1-2 秒。

为什么会慢

先定位问题，再对症下药。

80% 的性能问题来自包体积、首屏和接口。

优化 1：分包加载（最有效）

小程序主包限制 2MB，总包 20MB。把首屏用不到的代码分包：

分包策略

分包预加载

用户进入 A 页时，预加载 B 页（大概率会访问）：

"preloadRule": {
  "pages/index/index": {
    "network": "all",
    "packages": ["packageA"]
  }
}

预加载让用户感知不到分包切换。

独立分包

某些页面（如活动页）设为独立分包，不依赖主包，启动更快。

优化 2：首屏提速

用户第一眼看到的页面，决定体验。

1. 精简首页

2. 骨架屏

数据加载前显示骨架（占位框架），避免白屏：

骨架屏让用户"感觉快"。

3. 关键数据优先

先展示首屏可见区域的数据，其他懒加载：

• 首屏可见：立即加载。
• 滚动可见：滚动到再加载。
• 二级页面：进入再加载。

优化 3：接口优化

接口慢是性能杀手。

1. 接口合并

把多个小接口合并成一个大接口：

2. 接口并行

能并行的接口用 Promise.all：

Promise.all([
  api.getUser(),
  api.getProducts(),
  api.getConfig()
])

并行比串行快 2-3 倍。

3. 数据精简

接口只返回需要的字段：

4. 接口缓存

不常变的数据做缓存：

优化 4：图片优化

图片往往占流量 60% 以上。

一张 2MB 的图压到 100KB，加载快 20 倍。

优化 5：渲染优化

1. 减少 setData

setData 是同步操作，频繁调用会卡：

2. 列表虚拟化

长列表用虚拟列表（如 recycle-view），只渲染可见项。

3. 避免复杂 wxml

嵌套层数不超过 5 层，wxml 复杂度直接影响渲染。

优化 6：缓存策略

缓存层级

缓存失效

• 配置类：永久 + 定时刷新。
• 列表类：缓存 + 下拉刷新。
• 详情类：进入时校验。

性能监控

不做监控，没法持续优化。

关键指标

监控工具

• 微信开发者工具的 Performance 面板。
• 真机调试（开发者工具和真机差异大）。
• 自建埋点上报。

性能优化的成本

常见误区

• 不分析就优化：凭感觉优化，没找到真正瓶颈。
• 只优化前端：接口慢才是大头。
• 过度分包：分得太碎反而管理复杂。
• 不压缩图片：原图直传，浪费流量。
• 不监控：上线后没人管，性能慢慢变差。
• 优化一次就完：性能要持续维护。

怎么开始

1. 用真机 + Performance 面板定位瓶颈。
2. 按优先级优化（分包 > 首屏 > 接口 > 图片）。
3. 实施分包加载。
4. 精简首屏 + 加骨架屏。
5. 合并和优化接口。
6. 压缩和懒加载图片。
7. 上线监控埋点。
8. 持续优化 + 定期复盘。

广州市汉诺雷斯（HNREIS）做过多个小程序性能优化项目，能帮你定位瓶颈、做分包、首屏、接口、图片优化。把你的小程序性能问题告诉我们，我们给出方案与报价。