有用户在电梯里点开小程序，三秒过去还在转圈，出了电梯信号恢复，页面早被关掉了。老板把锅甩给开发，开发说代码没问题。性能这事不能靠吵架，微信小程序开发有一套现成的排查路径，顺着走就能找到瓶颈在哪。
先拆启动耗时
用户感知的打开慢由三段组成：代码包下载、框架初始化、首屏渲染。开发工具和后台的性能面板能把三段各拆出来看。包下载慢，问题在包体积和分发；渲染慢，问题在页面结构和数据量。诊断之前先分段，别凭感觉瞎优化，改了半天全花在不是瓶颈的地方，白忙一场还耽误发版。
工具就用官方那几样
微信开发者工具体验评分会直接列出扣分项：图片过大、接口太慢、频繁的页面跳转都逃不掉。真机调试比模拟器真实得多，用一台两年前的千元机跑一遍，很多在旗舰机上隐形的问题立刻现形。上线后看后台的性能监控大盘，看真实用户的启动耗时分布，P90那一栏比平均值更值得盯，它代表最慢的那批用户的体验，而抱怨往往就是他们发出来的。
两个最常见的代码病
第一个是数据传输不节制。把整个大对象一次性传给视图层刷新，数据里九成都是没变化的字段，页面自然卡。按需传、只传变了的部分，列表页尤其要控制单次数据量。第二个是同步接口滥用，启动链路里堆了一串同步读取，互相等待，首屏干等。能异步的异步，能缓存的缓存，把上一次的数据先渲染出来兜底，新数据到了再刷新，用户看到的永远是「已经打开了」的页面。
两条实在建议：把启动耗时写进微信小程序开发的上线验收标准，普通机型两秒内打开才算合格；发版后每周看一次性能大盘，比格网络的运维包里带着这项巡检，别等用户投诉了才想起来查。分段数据建议留存下来，几个版本对比着看，能发现是哪个改动让哪一段变慢。图片是最常见的隐形大户，列表页的缩略图别用原图地址，压缩版按尺寸出。体验评分的扣分项按影响排序逐个消，一周消两三项，一个月后大盘就有明显变化。优化要排优先级，先动影响面最大的：启动链路里每减少一次串行请求，所有用户都受益，比在角落页面抠几十毫秒划算。改完用同一台测试机复测，数据留档，别凭印象说变快了，慢是慢慢长回来的，性能是常态工作。性能这件事没什么一劳永逸，值得每次发版都回头看上一眼。
