作者：同一台手机，别家的小程序点开两秒进首页，你的还在转圈——先别怪用户的网络，九成的原因在代码里。而且慢这个事很公平：启动每多等一秒，就有一批用户直接退出，你花的推广费，有一部分是替那个转圈动画买的单。
动手之前先弄明白小程序启动的三步：下载包、注入代码、渲染页面。包越大下载越久，代码越多注入越慢，首屏接口越慢页面越白——所有优化都是围绕这三步做减法。下面按影响从大到小讲。
第一元凶：主包太大
微信小程序主包上限2M，但很多团队把上限当目标用，主包怼到1.9M——下载完、注入完才能渲染，慢是必然的。
实招有三层。基础操作是分包：把非核心页面（个人中心、设置、帮助）拆出去，主包只留首页和核心路径，压到1M以内，首屏体感立刻不一样。进阶一层是独立分包加分包预下载，用户还在逛首页时，后台就把下一步可能去的包提前拉好，点进去基本无感。再补一个按需注入（lazyCodeLoading），让当前页用不到的代码不参与启动注入。三板斧下来，启动耗时降一半是常见结果——主包从1.8M压到900K、配合预下载，冷启动从三秒多降到1.5秒上下，这种量级的改善在后台数据里直接可见。
第二元凶：首屏白屏，接口在串行跑
包下载完了，页面还白着，多半是首屏数据在拖。典型的低效写法：先请求用户信息，等返回了再请求商品列表，等列表回来再请求公告——三个接口串行，总耗时是三者相加。
改法：没有依赖关系的接口并行发；首屏关键数据做本地缓存，先用上次的数据把页面渲染出来（配个骨架屏，用户感知不到“慢”），新数据回来再刷新；顺手检查一遍接口，首页用不着的大字段让后端砍掉。一句话，让用户先“看见”页面，再等数据。至于接口本身慢——查询没加索引、一次返回几百条数据，这类问题前端怎么优化都救不了，把接口耗时打出来看看，别让前端背后端的锅。
图片：最容易被忽略的大头
打开任何一个小程序的性能面板看一眼，耗时排行榜上图片经常包揽前排。原图直传、没压缩、没有CDN裁剪，一张头图3M，用户那边的加载就是灾难。
处理起来不难：上传前统一压缩；列表页小图用缩略图，按显示尺寸向CDN要图（主流云服务都支持URL带参数裁剪）；格式换WebP，同画质体积小三分之一左右；首屏之外的图片全部懒加载。这几步做完，页面滑动流畅度会上一个档。
setData：新手踩得最多的坑
小程序的逻辑层和渲染层是分开的，页面更新靠setData把数据从逻辑层传过去。坑就坑在有人图省事，把整个列表甚至整页数据一次性set过去，或者在循环里高频调用——数据一多，传输和渲染都卡。
官方建议单次setData的数据量别超过256KB，实际体验里标准可以更苛刻：只set变化的那一项，列表更新按差量来，滚动、输入这类高频交互别触发setData。这个坑改起来不难，难的是写代码的人得知道有这回事——很多慢小程序，是按写网页的习惯写出来的。
最后一招是防复发：性能不是优化一次就完的。每个版本合入后跑一遍启动测试，主包体积设条警戒线（比如900K），超了当场处理。慢都是一点点长回来的，别让两个版本的新功能把优化成果吃回去。
优化的顺序就按上面来：先压主包，再理首屏，然后收拾图片和setData。前三项做完，首屏稳定进1.5秒并不难。动手前先看数据——开发者工具的体验评分和后台的启动性能面板会直接告诉你慢在哪，比凭感觉猜快得多。觉得自家小程序慢又说不清在哪的，把它发给我们做个启动性能体检（电话 18616880101，或联系我们），报告会写清楚每一秒花在了哪；微信小程序开发是我们的日常业务，要不要治、怎么治，你自己拍板。