给页面定性能预算：把"快"变成可验收的数字

#背景

"页面要快"是句正确但无法验收的话。落到日常开发里，它通常表现为：上线前大家觉得还行，三个月后没人记得当初是多少，于是每次加功能都"就多一点点"，一年后首页变成 800KB。

解法是定数字：把预算写下来，并让它能被自动检查。

#定预算

先看现状，再留余量。以本站首页为例（实测值）：

定这两个门槛的判断依据：

• 请求数比体积更影响体感：在移动网络下，多一个请求就是多一次往返（数百毫秒起）；
• HTML 的 gzip 后体积最能反映"服务端渲染是否干净"：9.8KB 说明没有把数据全塞进页面再让前端重排。

#自动守住

#1. 用命令随时复核

# 首页 HTML 的 gzip 体积
curl -s -H 'Accept-Encoding: gzip' https://vabora.dev/ | wc -c

# 请求数
curl -s https://vabora.dev/ | grep -c '<script'
curl -s https://vabora.dev/ | grep -c '<link rel="stylesheet"'

写进项目就以测试的形式固定下来（断言阈值，超了就红）：

$html = MarkdownService::render('...'); // 或抓取真实页面
$t->true(strlen(gzencode($html, 6)) < 12 * 1024, '首页 gzip 后 < 12KB');

#2. 视觉回归之外的"体积回归"

改样式时最容易悄悄变胖（多引入一个字体、多一张图、多一段动画）。所以体积断言要跟代码一起跑，而不是季度末人工体检。

#超预算时砍什么

按这个顺序做取舍，几乎总是对的：

1. 先砍第三方脚本：一个统计 + 一个客服 + 一个 A/B 工具，很容易超过你整站 CSS 的体积，而收益最不明确；
2. 再砍首屏图片：改成 CSS 渐变/图案，或用 <img loading="lazy"> 推后；
3. 再压字体：中文字体是重灾区，能只用系统字体就别自托管（本站的做法）；必须自托管时用 font-display: swap + 子集化；
4. 最后才讨论压缩与拆分：它们省的是百分比，而前三条省的是倍数。

#结果

• 首页 gzip 后 9.8KB、全站 CSS+JS gzip 后 28KB，移动网络下首屏基本瞬时；
• 加新功能时有明确的天花板：想加一个 20KB 的库，就得先说清砍掉什么；
• "性能"从主观感受变成数字，讨论成本大幅下降。

#取舍

• 不为一个指标牺牲可用性：比如为了少一个请求把 3 个页面的 JS 全合并，会让"改 A 影响 B"的风险上升。预算约束的是总量，不是逼你违背模块化。
• 不追 Lighthouse 满分：分数受环境影响大且波动明显，容易变成数字游戏。用固定命令量的体积与请求数更稳定可靠。
• 不做早期过度优化：预算的作用是"防退化"，不是"逼你现在就优化"。当前值离预算还远时，先把功能做对。