用户打开小程序，先白屏两三秒，流失就在这几秒里。首屏加载慢是小程序的老毛病，但多数情况能靠一套清单系统性解决，不必靠玄学。
第一项是包体积。主包超过 2M 会明显变慢，把非首屏的页面和组件拆到分包，用分包预下载在空闲时静默加载。图片、字体这类静态资源尽量走 CDN，别打进包里。
第二项是启动耗时。app.js 里的 onLaunch 别堆重逻辑，能延后的延后，能异步的异步。首页 onLoad 里只做必要请求，列表数据分页拉，别一进来就拉全量。
第三项是渲染。首屏用骨架屏占位，用户马上知道页面在加载，体感快很多。长列表用虚拟列表，只渲染可视区域，几千条数据也不卡。setData 是性能杀手，别传大对象，只改变化的字段。
第四项是网络。接口合并、开启 HTTP 缓存、关键数据本地缓存，二次打开基本秒开。如果接口本身慢，廷云信息一般会建议你加一层边缘缓存或把聚合逻辑放到服务端。
落地时建议先量后改：用小程序后台的性能面板看启动耗时和包体积，找出最慢的那一项优先处理，别平均用力。我们服务过的一个小程序，光是把首屏多余接口砍掉两个，启动就快了 40%。
落地时建议先量后改：用小程序后台的性能面板看启动耗时和包体积，找出最慢的那一项优先处理，别平均用力。我们服务过的一个小程序，光是把首屏多余接口砍掉两个，启动就快了 40%。
把首屏性能纳入每次发版的回归检查，新功能上线前先看一眼启动耗时有没有回退，体验才不会悄悄变差。
性能优化最怕一阵风，建议把启动耗时和包体积设成发版门禁，超标就卡住不让发。这样体验不会随版本悄悄劣化，团队也省去反复救火，新功能上线前先看一眼指标有没有回退。