Performance 统计首屏有 87 个请求 其中 31 个是图标和状态小图 每个都要排一次队 真正的首屏大图排到第四十位才发出。碰到这种情况,我一般先确认改动有没有真的生效。
原因不复杂,同域并发连接数有限 请求一多就只能排队 图标被拆成几十个小文件 每个都多一次往返 首屏关键资源只能往后等 时间全耗在排队上。
碰到「首屏请求数」这类问题,我习惯先把当前配置原样备份一份,改坏了立刻换回来,不用现场推。改完顺手把文档补一句,省得下次自己重新推一遍。
curl -s https://example.com | grep -c 'src=' npx lighthouse example.com --only-audits=network-requests
监控和日志的时间要对上,时区不一致会多绕很大一圈。
具体做法是,小于 5KB 的图标改成内联 SVG 或者合并到一张雪碧图里;首屏必需资源和次要资源分域存放 别让它们抢同一条连接;折叠线以下才用到的组件改成懒加载 首包只留首屏依赖。
最后用这个标准收尾,首屏请求降到 40 个以内 关键图片进到前十 首屏时间明显前移。
