微信小程序性能优化实战：从 3 秒到 0.8 秒的加载优化之路

我们做过一个把小程序首屏从 3.2 秒压到 0.82 秒的项目。做法不复杂，难的是"先量再改"——这篇按定位、优化、上线后观察三步讲，末尾有优化前后的对比数据。

第一步：先弄清楚慢在哪

小程序性能问题有三个不同的来源，对应的手段完全不同，混着改往往白忙：

• 包体积太大：下载与解析耗时都高，表现为"首次打开慢、二次打开就快"。
• 首屏数据请求慢：骨架屏出来得早，但内容迟迟不上——问题在接口与串行请求。
• 渲染卡顿：内容能出来，但滚动、点击有延迟——问题在 setData 的数据量与频率。

我们的做法是：真机上用性能面板看首屏各阶段耗时，配合分包体积分析，再统计一次首屏加载期间 setData 的调用次数与数据量。三个数一摆出来，主因基本就清楚了。

第二步：包体积从 2.8MB 降到 790KB

1. 分包加载。商品详情、购物车、个人中心拆成独立分包，主包只保留首页框架、导航与全局配置，控制在 800KB 以内。分包后要顺带处理"首个分包页面打开白屏"——做法是提前预热分包或用分包预下载。
2. 图片。统一走 CDN 处理（格式转换 + 按尺寸裁剪），首屏关键图本地打包避免网络往返，非关键图懒加载。图片往往是小程序体积里最大的一块。
3. 依赖瘦身。日期库从 Moment 换成 Day.js；工具函数按需引入，不整包引 Lodash；组件库只引实际用到的组件。
4. 构建。开启上传时压缩代码，并确认构建工具做了 Tree Shaking（打包后仍要复核产物体积，配置了不等于生效）。

第三步：首屏数据"缓存优先 + 静默更新"

首屏数据采用先渲染本地缓存、再静默刷新：打开小程序先展示上次的数据（骨架屏 + 缓存内容，几十毫秒内可见），同时发请求，拿到新数据后平滑替换。这样"看到内容"的时间不再依赖接口响应。

配合三件事：把首屏必须的接口合并成一个（避免串行瀑布）、非关键数据（推荐、评价）分页懒加载、接口走 HTTP/2 复用连接。我们在这个项目里还把部分数据格式化的逻辑挪到视图层执行，减少跨层通信次数。

第四步：渲染——管住 setData

setData 是小程序性能的头号变量：数据量越大、调用越频繁，跨层通信的开销越明显。我们的做法是"只发变化的部分"——用 diff 而不是整体覆盖，长列表只更新可视区域内的项；静态格式化（价格、日期）尽量在视图层完成，不把格式化后的结果再塞回逻辑层。

长列表页面用虚拟列表（只渲染可视区上下各一屏），实测在 500 条以上数据时滚动仍能保持稳定帧率。

上线之后要盯什么

优化不是发布完就结束。我们在项目里持续观察三个指标：首次打开与二次打开的首屏耗时（分开看）、分包加载失败率、接口 P95 耗时。缓存优先策略还要特别注意一致性：缓存必须有版本号或过期时间，否则用户会看到"改不掉的旧数据"——我们吃过一次亏，后来把缓存版本与后端数据版本绑在一起才彻底解决。

如果你的小程序也卡在"首屏三秒以上"，可以先按上面第一步把三个数测出来，再决定改哪里。需要人一起看的话，我们在小程序端做过不少这类性能专项，欢迎联系我们。