去年冬天我们在客户会议室用一台用了两年的安卓机反复点开那个茶叶小程序，旁边放着秒表。首屏 3 秒多，偶尔到 4 秒。客户没抱怨，是我们自己看着别扭。
先说怎么量的。微信开发者工具里看的不算数，真机差别大。我们用的是小程序自带的 trace 加上在 app.js 的 onLaunch、首页 onLoad、onReady 三个点打时间戳，把三段耗时打到后台一张表里，连着测了 20 次取中位数。不这么干，改完没法说清到底快没快。
第一件：图片
主包里塞了 11 张图，轮播 3 张、分类图标 8 张，全是 PNG，加起来 1.2M。挪到 CDN，切成 webp，按屏幕宽度请求对应尺寸，图标换成字体图标。这一下主包少了将近 900K。
有个小坑：webp 在当时的低版本安卓上不支持，我们留了 PNG 兜底，靠请求头判断。不多，几行代码。
第二件：分包
4 个页面平时没人点：品牌介绍、加盟说明、历史订单详情、帮助中心。原来全在主包里，首屏加载时一并下发了。拆成一个 subpackage，主包只留首页、分类、商品详情、购物车。微信那时候主包上限 2M，我们原来 1.9M，已经贴着线了。
拆的时候发现有个公共的 utils 被主包和分包都引了，重复打进去了。提到主包里共用，又省了一点。分包预下载配了两条规则，进首页后闲时拉，用户点过去就不用等。
第三件：请求
首页原来发 3 个请求：轮播、分类、推荐商品。三个接口串行等，网络稍差就叠出 1 秒多。合并成 1 个 home 接口，后端 PHP 一次查完打包返回，接口数 3 变 1。响应体大了些，但省下的是两次往返。
顺手给首页数据加了 Redis 缓存，300 秒，跟之前官网那套一样。
改完
主包 1.9M 到 1.1M，20 次真机测下来中位数 1.8 秒，最慢一次 2.3 秒，是会议室 Wi-Fi 抽风。没有动框架，没有换服务器，没有加机器。
后来我们把这套量法写进了交付清单：改性能之前先定怎么量，不然「感觉快了」这种话没法写进验收单。
那天收工挺早，客户会议室的暖气很足，秒表借来没还。
