一个人优化不完所有页面，只能先算清哪一处最慢、哪一笔最贵。
这个系列解决什么问题
一个人做产品，性能清单总是排在功能后面：Lighthouse 有几十条建议，每个框架都有一份优化指南，每一条都写着「应当」。做完不可能，不做又眼看着用户在转圈。
这个系列不讲「某个指标怎么测」，也不复述前端、基础设施与可观测性专题里的技术细节。它讲的是取舍：四条预算里哪一条先立；五条关键路径里哪一条先修；1,200 次查询里哪三次能合并；缓存的三层各留多久；七个第三方标签里删哪三个；210 美元的账单里哪一项最值得动；以及一次发布把 p95 从 320 推到 980 毫秒之后，门禁该怎么补。
它服务的是一个没有 SRE、没有前端团队、也没有 FinOps 的人。 你能投入的不是一套性能平台，而是四个数字、一张五条路径的预算表、一条「先测再改」的规矩和一条「预算进 CI」的门禁。
核心主张：五条口径
- 性能是预算题，不是分数题。 四项预算写成能复算的数字，比追一个满分更有用。
- 先测再改。 没有 RUM 与慢查询日志的优化，多半在改自己以为的瓶颈。
- 用户感知优先，但不只看用户感知。 首屏 4.2 秒与 p95 1,240 毫秒要放在同一张桌上。
- 账单是性能的另一面。 传输体积、回源次数与查询次数同时决定快慢和成本。
- 回归靠门禁，不靠自觉。 性能不会自己变好，但会自己变坏。
10 篇速览
| # | 文章 | 核心内容 | 阶段 |
|---|---|---|---|
| 01 | 性能是一份预算：四项指标、二十格与四十小时 | 4 项预算、5 路径、4/20→20/20、40 h | 预算 |
| 02 | 先测再改：RUM、慢查询日志与一次改错的优化 | RUM 12,600 条/月、5.0 MB、5 h | 测量 |
| 03 | 首屏：412 KB 的去处与一次 1.8 秒的字体阻塞 | 412→168 KB、LCP 4.2→1.8 s | 首屏 |
| 04 | 数据库：一千二百次查询、三个索引与 8 秒的列表页 | 1,200→3 次、8.0→0.35 s | 查询 |
| 05 | 缓存：三层、86% 命中与一次 11 分钟的旧数据 | 60/300/300 s、0→86% | 缓存 |
| 06 | 后台任务：34 秒的同步导出与三次重复文件 | 34→4 s、1.98 h/月、4.2 MB | 异步 |
| 07 | 第三方脚本：七个标签、640 KB 与一次被拖慢的登录 | 7→4、640→180 KB | 第三方 |
| 08 | 云账单：210 美元的去处与每千次请求 0.42 | 210→118、0.42→0.19、年省 1,104 | 成本 |
| 09 | 性能回归与门禁：一次发布后 p95 从 320 到 980 | 26 次发布、3 次告警、5 h | 门禁 |
| 10 | 性能验收：十项指标、四维评分与季度复测 | 10 项、1.90→4.03、4 h | 验收 |
三条阅读路径
路径 A：刚上线，首页要 4 秒。 先读 02 把 RUM 与慢查询日志接上，再读 03 把首屏 412 KB 拆开，最后用 01 把四条预算立起来。这条路径的重点是「先知道慢在哪，再动手」。
路径 B：有几百个用户，说不清哪里慢。 先读 04 把列表页的 1,200 次查询收掉，再读 05 上三层缓存，用 06 把 34 秒的导出改成异步。这条路径的重点是「把最贵的一次请求变便宜」。
路径 C：账单在涨，或要接企业客户。 先读 08 把 210 美元拆成五项，再读 07 删掉三个第三方标签，最后用 09 与 10 把预算写进 CI 并做一次季度验收。这条路径的重点是「快与省同时可证明」。
与其它专题的边界
站内已有前端、基础设施、可观测性、运维、架构与各组验收内容，但都不处理「一个人怎么用 40 小时给性能与成本排序」这条线。下表说明本组不重复什么。
| 既有内容 | 它讲什么 | 本组边界 |
|---|---|---|
| 前端工程专题 | Core Web Vitals、bundle 分析、性能调试与构建优化 | 它给每项技术的做法；本组给一个人 40 小时的取舍、排序与验收 |
| 基础设施专题 | 缓存策略、连接池、数据库索引、容量与网关 | 它给组件级方案；本组给跨组件的预算与实测 |
| 可观测性专题 | RUM、持续剖析、指标、日志与追踪平台 | 它讲怎么采集；本组讲用哪十个数字做决定 |
| 一个人的运维：可用性、告警、事故与值班 | 可用性预算、五条探针、容量水位、扩容顺序 | 它管「别挂」与「何时加钱」；本组管「同样容量下快不快、贵不贵」 |
| 一个人的架构：技术选型、模块边界与演进 | 选型排除法、模块边界、后台任务的幂等与补偿 | 它管选型与一致性；本组管选完之后的预算与实测 |
| 一个人的财务：现金流、runway 与月度结账 | 四张表、成本清点、runway 与月度结账 | 它算整体现金；本组只降云账单这一个成本项 |
| 一个人给产品加 AI：判据、成本、护栏与验收 | 推理账单、每用户成本、p95 首 token 与降级 | 它管 AI 链路；本组管页面、查询、缓存与基础设施 |
| 一个人的质量守门：验证预算、回归清单与发布门禁 | 关键路径、回归分层、六项发布门禁与缺陷分级 | 它管功能对不对；本组管同样功能快不快、贵不贵 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 攻击面、密钥、四条边界、限流与安全验收 | 它管别被破；本组管别慢到不能用 |
| 一个人的产品度量：事件字典、指标口径与决策看板 | 事件字典、口径五要素、漏斗与数据质量 | 它量用户行为；本组量系统状态与单位成本 |
| 一个人的数据搬家：导入、去重、迁移与退出 | 导入契约、去重、迁移窗口、附件与导出四件套 | 它管数据进出契约；本组管导出任务不超时 |
| 一个人把软件交付到用户手里 | 签名公证、安装包、更新器与商店审核 | 它管分发链路；本组管传输体积与加载 |
| SaaS 创业专题 | 团队协作、增长工程与商业计划语境 | 它按团队算成本；本组按一个人算 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲企业采购与合同；本组讲性能预算、首屏、查询、缓存与云账单 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲开源项目的依赖与告警；本组讲性能预算、首屏、查询、缓存与云账单 |
这十篇不教框架调优，不承诺「快一倍」，也不评价任何厂商产品。可复算的部分全部用四则运算给出算式；不可复算的部分（浏览器行为、平台计费规则）明确指向官方文档。所有数字都是教学假设，代入前请换成自己的页面数、查询数与账单。
本组统一口径
全组共用一组教学假设，各篇引用时不换分母：
产品：一人 SaaS 任务板，与既有组同一产品；账号 344，付费 120
技术：单体 + Postgres + 对象存储 + CDN；直接依赖 41
时间：一年 48 周 × 40 h = 1,920 h
关键路径 5 条：首页、项目列表、任务详情、设置、导出
改前：LCP 4.2 s；首屏 412 KB；API p95 1,240 ms；列表页 1,200 次查询 / 8.0 s
缓存命中 0%；导出同步 34 s；第三方 7 标签 / 640 KB
账单 210 美元 = 计算 96 + 数据库 54 + 存储 18 + 出站 32 + 其它 10
月请求 50 万次 × 700 KB ≈ 350 GB；每千次 210 ÷ 500 = 0.42 美元
改后：LCP 1.8 s；首屏 168 KB；p95 320 ms；列表页 3 次查询 / 0.35 s
缓存命中 86% = 72% × 98% + 28% × 55%；导出 4 s 受理 + 12 s 完成
第三方 4 标签 / 登录页 180 KB；账单 118 美元 = 48 + 42 + 12 + 12 + 4
月请求 62 万次 × 190 KB ≈ 118 GB；每千次 118 ÷ 620 = 0.19 美元
性能预算 4 项：LCP ≤ 2.0 s；首屏 ≤ 200 KB；p95 ≤ 400 ms；查询 ≤ 5 次
预算格 = 4 项 × 5 条路径 = 20 格；改前 4/20 达标，改后 20/20 达标
全年 40 h = 诊断 5 + 首屏 5 + 查询 7 + 缓存 4 + 后台 4
+ 第三方 3 + 账单 3 + 门禁 5 + 复测 4 = 1,920 h 的 2.1%
年省 = (210 − 118) × 12 = 1,104 美元；回本时薪门槛 = 1,104 ÷ 40 = 27.6 美元/h
40 小时是全年投入，不是某一次优化。 它包含一次性修复（首屏、查询、缓存、后台任务）与年度动作（诊断、账单治理、门禁、季度复测）。
20 格是检查表，不是评分表。 它只回答「这条路径的四项预算是否达标」，不回答「体验好不好」；体验仍要回到真实用户。
账单省下的钱不等于利润。 1,104 美元是云账单这一项的差额；它要先进现金账，再谈投入产出。
使用说明
先立四条预算，再谈优化。 没有阈值的优化没有终点；阈值要写清楚是 p75 还是 p95、在什么网络下测的。
测量工具越少越好。 一个 RUM、一份慢查询日志、一条每周合成测试，足够一个人用；多出来的平台只会多一个要维护的看板。
缓存先想失效。 三层缓存的收益是 86%，代价是最坏 11 分钟的旧数据；写后失效的规则要在上线前写好。
门禁要能自动失败。 预算写进 CI 却不阻断合并，等于没有预算。
本组的证据与使用方法
证据类型。 本组用的是「四条预算与 20 格检查表 + 12,600 条/月 RUM 记录 + 1,200→3 次查询的前后对比 + 86% 缓存命中 + 210→118 美元的账单 + 一次 p95 980 的回归记录」。没有「最佳实践」式的断言。
如何使用。 先用 01 立预算，再用 02 接测量，按 03–07 的顺序修最贵的五处，最后用 09 与 10 把门禁与验收固定下来。
如何复核。 取最近一次性能改动：看改前有没有测量、改后有没有复测、预算有没有进 CI、账单有没有按月对比。四项都能对上，这套基线才适用。