分数是别人的尺子，预算是自己的。
一、一次「分数很好但用户说慢」的对话
2026 年 9 月 18 日，客服转来一封邮件，只有两行：客户说任务板「点开要等半天」，附了一张手机截图，白屏中间一个转圈。他当天下午打开自己的 Lighthouse，首页 98 分，移动端 96 分，四项核心指标全绿。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
晚上他用手机在 4G 下打开同一个页面，首屏 4.2 秒。分数和体感之间的差距不是仪器坏了，而是两者测的不是同一件事：实验室跑的是受控环境，缓存为空但网络很快；客户用的是 p75 慢网 1.6 Mbps，账号里有 100 个项目，浏览器里还压着上一次的旧缓存。
他先怀疑是客户网络差。第二天他拿同一台手机、同一张 4G 卡打开别的产品，再打开自己的，两次的差别只能来自页面本身。同一条网络、同一台设备、同一个浏览器，这一条排除法比任何分数都直接。
他把过去三个月的抱怨邮件按页面归类，落点只有五条路径：首页、项目列表、任务详情、设置、导出。导出甚至不是慢，是失败——34 秒的同步导出撞上网关 30 秒超时，用户看到的是错误页，不是等待。
这五条路径不是按页面大小选的，是按「用户在哪一步停下」选的：首页停下是没进来，列表停下是找不到，详情停下是不敢点，导出停下是白等一场。设置页是唯一一条抱怨几乎都指向文案而不是等待的路径。
那天晚上他没有改一行代码。他做了另一件事：给这五条路径各写四个上限，把「快」从形容词变成四个可以复算的数字。
二、四项预算与五条路径
| 预算 | 阈值 | 改前 | 改后 |
|---|---|---|---|
| 首屏 LCP p75 | ≤ 2.0 s | 4.2 s | 1.8 s |
| 首屏传输 | ≤ 200 KB | 412 KB | 168 KB |
| API p95 | ≤ 400 ms | 1,240 ms | 320 ms |
| 列表页查询 | ≤ 5 次 | 1,200 次 | 3 次 |
四个数字不是随便挑的：一个管用户感受（LCP），一个管传输体积（KB），一个管服务端（p95），一个管数据库（查询次数）。从浏览器到数据库，一条链四个关口，再加第五个就没人看了。
阈值也不是拍出来的。200 KB 来自慢网：p75 下行 1.6 Mbps 即 1,600 Kbps，传 200 KB 需要 200 × 8 ÷ 1,600 = 1.0 秒，刚好是「还愿意等」的传输时间。LCP 2.0 秒是这条传输时间加上 TTFB 与渲染之后的剩余额度。API p95 400 ms 对应首屏四段里的 TTFB 0.4 秒。列表页 5 次查询，是「一次主查询加两次聚合，不超过一只手」。
四项里最容易写错的是 p95。它必须是 p95，不能是平均值：平均值会把最慢的一批请求藏起来，而那批请求恰好来自数据最多、付钱最多的账号。把平均值写进预算，等于给自己发一张及格证。
阈值每年只调一次。调得太勤，格子会变成追着自己跑；从不调，格子会脱离用户。调阈值的那一天要写下理由，否则下一季度复测时，没人说得清为什么是 200 KB 而不是 180 KB。
五条路径而不是全部页面，因为预算是注意力合约。二十个格子已经需要每季度复测一次；把所有页面都写进预算，第一次复测就会放弃。
三、二十格怎么打分
| 路径 | LCP ≤ 2.0 s | 首屏 ≤ 200 KB | p95 ≤ 400 ms | 查询 ≤ 5 次 | 改前 | 改后 |
|---|---|---|---|---|---|---|
| 首页 | ✗ 4.2 s | ✗ 412 KB | ✗ 1,240 ms | ✗ | 0/4 | 4/4 |
| 项目列表 | ✗ | ✗ | ✗ 1,240 ms | ✗ 1,200 次 | 0/4 | 4/4 |
| 任务详情 | ✗ | ✗ | ✗ | ✗ | 0/4 | 4/4 |
| 设置 | ✓ | ✓ | ✓ | ✓ | 4/4 | 4/4 |
| 导出 | ✗ | ✗ | ✗ 34 s | ✗ | 0/4 | 4/4 |
二十格是四项预算乘五条路径。改前只有 4 格达标，全部来自设置页——那是一条轻路径，四个指标本来就在阈值内；表里 1,240 ms 是全站聚合值，不是这一条路径的值。其余四条路径一共 16 格全空：首页 LCP 4.2 秒、首屏 412 KB，列表页 1,200 次查询，导出 34 秒。改后 20 格全过：LCP 1.8 秒、首屏 168 KB、API p95 320 ms、列表页 3 次查询。
不打平均分，是因为平均分会把最坏的一格稀释掉。一条 4.2 秒的路径和四条达标路径平均之后，看起来「接近达标」，但用户记住的正是那 4.2 秒。格子制只说一件事：一格不过就是不过，不给部分分。
格子还负责排序。改前空了 16 格，但十六格的价值并不相同：设置页那 4 格本来就在，首页那 4 格影响每一个新用户，导出那 4 格影响的是「能不能用」。同样是 1 格，先补哪一格，要看它站在哪条路径上。
这也是为什么不把格子做成加权总分。权重一旦出现，就会有人去算「差一点要不要修」，而预算要的回答只有「过」或「不过」。
打分条件必须固定：同一台设备、同一条网络、同一个账号、同一批数据。条件一换，格子就会失真；而失真的格子比没有格子更糟，因为它会给出一个看起来精确的错误结论。
四、四十小时怎么分
| 项目 | 小时 | 产出 |
|---|---|---|
| 诊断 | 5 | 按路径排序的瓶颈清单 |
| 首屏 | 5 | LCP 4.2 → 1.8 s，412 → 168 KB |
| 查询 | 7 | 列表页 1,200 → 3 次，8.0 → 0.35 s |
| 缓存 | 4 | 命中率 0% → 86% |
| 后台任务 | 4 | 导出 34 s → 4 s 受理、12 s 完成 |
| 第三方 | 3 | 登录页 640 → 180 KB，7 → 4 个标签 |
| 账单治理 | 3 | 月账单 210 → 118 美元 |
| 门禁与监控 | 5 | 四项预算进 CI |
| 季度复测 | 4 | 四次复测，每次 1 h |
顺序按「一格值多少小时」排，不按格子数排。诊断 5 小时排第一，因为它决定后面 35 小时花在哪里；不做诊断，首屏那 5 小时很可能花在图片上，而真正的阻塞在字体。
首屏 5 小时换回的是感受：LCP 4.2 → 1.8 秒，首屏 412 → 168 KB。查询 7 小时是九项里最贵的，因为它要动数据访问结构，不只是加索引；换回的是列表页 8.0 → 0.35 秒。
这也解释了为什么「先做首屏」在很多时候是错的。如果诊断发现瓶颈在数据库，首屏的 5 小时只能拿回传输体积那一部分，而查询的 7 小时能同时松开列表、详情与导出三条路径。顺序的价值不在哪一项更酷，而在哪一项能同时点亮更多格子。
缓存、后台任务、第三方三项都以改配置为主，单小时收益高，所以放在查询之后：先把查询降下来，缓存才有意义，否则只是把慢结果缓存得更久。
账单治理 3 小时没有直接让页面变快，它让同一套改动在账单上兑现。门禁与监控 5 小时买的是「不退回」，季度复测 4 小时买的是「知道有没有退」。
九项里没有一项叫「重写」。一个人的性能工作更像是把已有的东西挪到正确的位置：索引挪到查询上，字体挪到子集里，导出挪到队列里。重写是把预算押在一次大改上，挪位置是把预算摊在九次小改上。
全年 40 小时，是 1,920 小时的 2.1%。年省 (210 − 118) × 12 = 1,104 美元，回本时薪门槛是 1,104 ÷ 40 = 27.6 美元。这个门槛的意思是：只要你的时间每小时值超过 27.6 美元，这 40 小时就值得花；低于它，该先减功能或先涨价，而不是先做性能。
复算：
四项预算 × 五条路径 = 4 × 5 = 20 格
改前达标：设置页 4 格 = 4 ÷ 20 = 20.0%，其余四条路径 0 格
改后达标：20 ÷ 20 = 100%
投入：5 + 5 + 7 + 4 + 4 + 3 + 3 + 5 + 4×1 = 40 h
占比：40 ÷ 1,920 = 2.08% ≈ 2.1%
年省：(210 − 118) × 12 = 92 × 12 = 1,104 美元
回本门槛：1,104 ÷ 40 = 27.6 美元/h
传输下限：200 × 8 ÷ 1,600 = 1.0 s
复算里最容易被跳过的是最后一行。200 KB 不是审美选择，是 1.6 Mbps 下 1 秒的传输量；如果目标用户里有相当一部分在更慢的网络里，这个阈值要往下调，而不是往上调。
五、行动清单与复算验收
- 写下四条预算的阈值，每条都配一个能算出这个阈值的算式。
- 选出五条承接抱怨最多的路径，其余页面先不管。
- 画出 4 × 5 的格子，用当前值逐格标注过或不过。
- 数出改前达标格数，记下分母 20，不写成百分比。
- 按「一格值多少小时」把四十小时排成顺序，而不是按工程量。
- 给每一项投入写一个可观测的产出，写不出产出的项删掉。
- 用最近一个月的账单算出年省，再除以总小时数得到回本门槛。
- 把 20 格与阈值写进季度复测模板，复测只填数不改阈值。
验收标准：任取一条路径，都能说出它四项预算的当前值、阈值与最近一次复测日期。
前四条是「把账算出来」，后四条是「让账能重复」。如果只有一周，先做第一条和第三条；没有阈值和格子，四十小时的分配只是感觉。
清单里最容易被跳过的是第二条：只选五条路径。人总想一次覆盖所有页面，但预算的第一个作用是排除，第二个才是覆盖；不先排除，二十格会摊成一张没有边界的清单，第二周就停更。
使用边界与实操验收
预算只对自己有效。 四项阈值来自这款产品的五条路径与 p75 慢网，不是行业标准。换一个产品、换一批用户，200 KB 与 2.0 秒都可能不成立，唯一可以搬走的是「四项、五路径、二十格」这个结构。
二十格不是评分卡。 它的用途是排序与验收，不是给产品打分。20/20 不代表没有性能问题，只代表这二十个格子在这个季度都守住了。
省下的钱不等于赚到的钱。 1,104 美元是账单差额，不含这 40 小时的机会成本；把它当成「多出来的现金」会高估收益。
格子要复测才算数。 20 格是某个季度的快照，不是永久状态。发布十几次之后如果不复测，20/20 会在某一次发布里悄悄变成 18/20，而你不会收到通知。
数字是教学假设。 344 个账号、120 个付费用户、210 美元账单与全部时长都取自本组统一基线，不构成对任何产品性能或成本的预测。
关键参考与核验范围
- MDN: Web Performance ：用于核对首屏性能指标的通用定义与测量入口。
- MDN: LargestContentfulPaint ：用于说明 LCP 的口径与分段依据。
- FinOps Foundation: FinOps Framework ：用于说明账单与工程动作如何对齐到同一套口径。
- AWS Well-Architected: Cost Optimization Pillar ：用于核对成本优化的常见类别，不用于推导本文金额。
以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。
范围上只讨论一个人的性能预算、格子打分与四十小时排序，不讨论框架选型、CDN 厂商对比与团队分工。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。