performance-budget

性能预算技能

为 Web 服务或应用生成一份完整、可执行的性能预算文档。性能预算不是愿望清单，而是一组可衡量、可强制执行的约束，用于定义什么是“可接受的性能”，以及当这些约束被违反时由谁负责。

一份优秀的性能预算会回答：目标是什么、如何衡量、什么情况会触发调查，以及超出预算时会采取什么措施。

必要输入

如果尚未提供，请询问以下信息：

• 服务名称和类型 — Web 应用、API 服务、移动应用或组合类型
• 关键用户旅程 — 用户最重要的 3–5 个流程（例如“搜索 → 商品页 → 结账”）
• 当前基准指标 — P50/P95/P99 延迟、LCP、CLS、INP（如有）（如果尚未收集，请注明“无基准数据”）
• 技术栈 — 前端框架、后端语言/框架、CDN、数据库
• 部署环境 — 云服务提供商、区域、边缘/CDN 配置
• 成本限制 — 影响余量的预算或基础设施限制

输出格式

---

性能预算：[服务名称]

服务：[名称] | 团队：[团队名称] 最近更新：[日期] | 负责人：[姓名/角色] 环境：[生产环境/暂存环境基准] | 审核频率：[每季度/每个冲刺]

---

概述

[用 2–3 句话描述该服务、面向用户的性能要求，以及性能为何是优先事项。说明延迟对业务的影响，例如转化率、用户留存率、SLA 义务。]

性能理念：[例如：“性能是一项功能。每位工程师都有责任确保服务不超出预算。必须在 CI 中发现性能回退，避免其进入生产环境。”]

---

关键用户旅程

定义性能预算旨在保障的关键路径。

旅程 ID	旅程名称	入口点	退出点	重要性
UJ-1	[例如：新用户注册]	[落地页]	[控制面板]	关键
UJ-2	[例如：核心工作流任务]	[例如：/app/tasks]	[例如：任务完成]	高
UJ-3	[例如：搜索并选择]	[例如：/search]	[例如：详情页]	高
UJ-4	[例如：获取 API 数据]	[例如：GET /api/items]	[例如：200 响应]	中

---

前端性能预算

Web 和移动应用请填写本节。仅提供 API 的服务可跳过。

Core Web Vitals 目标

除非另有说明，目标适用于真实用户会话（现场数据）的第 75 百分位数，测量设备为中端 Android 设备，网络为 4G。

指标	描述	良好	需要改进	差	我们的目标	当前基准
LCP	最大内容绘制 — 感知加载速度	≤2.5s	2.5–4.0s	>4.0s	[≤X.Xs]	[Xs/未测量]
INP	下次绘制交互 — 响应能力	≤200ms	200–500ms	>500ms	[≤Xms]	[Xms/未测量]
CLS	累积布局偏移 — 视觉稳定性	≤0.1	0.1–0.25	>0.25	[≤0.X]	[X.XX/未测量]
FCP	首次内容绘制	≤1.8s	1.8–3.0s	>3.0s	[≤X.Xs]	[Xs/未测量]
TTFB	首字节时间	≤800ms	800ms–1.8s	>1.8s	[≤Xms]	[Xms/未测量]

页面体积预算

资源类型	最大体积（压缩后）	当前值	状态
页面总体积	[例如：500KB]	[XKB/未知]	[符合/超出/未知]
JavaScript（初始加载）	[例如：200KB]	[XKB/未知]	[符合/超出/未知]
CSS	[例如：50KB]	[XKB/未知]	[符合/超出/未知]
图片（首屏以上）	[例如：150KB]	[XKB/未知]	[符合/超出/未知]
Web 字体	[例如：50KB]	[XKB/未知]	[符合/超出/未知]
第三方脚本	[例如：100KB]	[XKB/未知]	[符合/超出/未知]

按用户旅程划分的前端目标

用户旅程	LCP	INP	CLS	FCP	TTFB
UJ-1：[用户旅程名称]	[≤Xs]	[≤Xms]	[≤0.X]	[≤Xs]	[≤Xms]
UJ-2：[用户旅程名称]	[≤Xs]	[≤Xms]	[≤0.X]	[≤Xs]	[≤Xms]
UJ-3：[用户旅程名称]	[≤Xs]	[≤Xms]	[≤0.X]	[≤Xs]	[≤Xms]

---

后端性能预算

API 延迟 SLO

目标在服务边界处测量（不包括客户端网络延迟）。

端点 / 操作	方法	P50	P95	P99	最大值（硬性限制）	错误率
[例如 /api/auth/login]	POST	[≤Xms]	[≤Xms]	[≤Xms]	[≤Xms]	[<X%]
[例如 /api/items]	GET	[≤Xms]	[≤Xms]	[≤Xms]	[≤Xms]	[<X%]
[例如 /api/items/:id]	GET	[≤Xms]	[≤Xms]	[≤Xms]	[≤Xms]	[<X%]
[例如 /api/items]	POST	[≤Xms]	[≤Xms]	[≤Xms]	[≤Xms]	[<X%]
[例如 后台作业：同步]	—	[≤Xs]	[≤Xs]	[≤Xs]	[≤Xs]	[<X%]

整体服务 SLO：

SLO	目标	测量窗口
可用性	[99.X%]	滚动 30 天
P95 延迟（所有端点）	[≤Xms]	滚动 30 天
错误率（5xx）	[<X%]	滚动 30 天
吞吐量（持续）	[≥X req/s]	高峰时段

数据库查询预算

查询 / 操作	P50	P95	最大值	备注
[例如 按 ID 查找用户]	[≤Xms]	[≤Xms]	[≤Xms]	在 user_id 上建立索引
[例如 列出用户的项目]	[≤Xms]	[≤Xms]	[≤Xms]	分页，最多 100 行
[例如 全文搜索]	[≤Xms]	[≤Xms]	[≤Xms]	Elasticsearch / pg_trgm

---

测量方法

真实用户监控（RUM）

工具： [例如 Google CrUX、SpeedCurve、Datadog RUM、Sentry Performance、自定义工具] 数据来源： [真实用户的现场数据 / 合成测试的实验室数据 / 两者] 采样率： [X% 的会话] 访问方式： [仪表板 URL 或工具访问说明]

测量内容：

• 按页面和用户旅程统计核心 Web 指标（LCP、INP、CLS）
• 业务关键交互的自定义性能标记
• 关键资源的资源计时
• 长任务（主线程上 >50ms）

合成监控

工具： [例如 Lighthouse CI、WebPageTest、k6、Artillery、带性能断言的 Playwright] 频率： [每 X 分钟 / 每次部署时 / 每晚] 测试位置： [例如 eu-west-1、us-east-1] 设备配置： [桌面端 10Mbps / 移动端 4G Moto G4 / 两者]

合成测试套件位置： [测试文件链接]

后端可观测性

APM 工具： [例如 Datadog、Grafana + Prometheus、New Relic、AWS X-Ray] 收集的指标：

• 按端点统计请求率、错误率、持续时间（RED 指标）
• 数据库查询持续时间和连接池利用率
• 缓存命中率 / 未命中率
• 后台作业队列深度和处理延迟

仪表板： [主要性能仪表板链接]

---

CI/CD 性能强制检查

性能预算通过以下两个关卡强制执行：

关卡 1 — 构建时 Bundle 分析

工具： [例如 bundlesize、size-limit、带 CI 断言的 webpack-bundle-analyzer] 配置文件： [[.bundlesizerc / .size-limit.js / etc.]] 触发条件： 每个目标为 main 的 PR 是否阻止合并： 是 — 如果超出 Bundle 大小预算，PR 无法合并

// Example .size-limit.js
[
  {
    "path": "dist/js/*.js",
    "limit": "200 KB"
  },
  {
    "path": "dist/css/*.css",
    "limit": "50 KB"
  }
]

关卡 2 — CI 中的合成性能测试

工具： [例如 Lighthouse CI、k6、Artillery] 触发条件： 部署到 staging 时 是否阻止发布： 是 — 如果阈值不达标，则阻止发布到生产环境 检查的阈值：

• LCP ≤ [Xs]
• CLS ≤ [0.X]
• API P95 延迟 ≤ [Xms]
• 错误率 < [X%]

CI 配置位置： [[.github/workflows/perf.yml / ci/performance.yaml]]

如何在本地运行：

# Run Lighthouse CI against local build
[command — e.g. lhci autorun --config=lighthouserc.js]

# Run load test locally
[command — e.g. k6 run load-tests/api-smoke.js]

---

预算超标响应流程

当测量指标超过目标并持续 [连续 X 次测量 / 持续 X 分钟 / 单次部署] 时，即视为预算超标。

超限严重程度级别

严重程度	条件	响应时间	处理人员
P1 — 严重	生产环境中超过预算阈值的 2 倍	立即	值班工程师 + 团队负责人
P2 — 高	生产环境中超过预算阈值的 1.5 倍	4 小时内	值班工程师
P3 — 中	生产环境中超过阈值	1 个冲刺内	PR 作者 + 团队
P4 — 低	仅在预发布环境中超过阈值	合并前	PR 作者

超限调查清单

检测到超限时，请按顺序完成以下检查：

1. 找出导致回归的提交

# Compare performance across recent deploys
[command — e.g. datadog metrics query, lighthouse-ci compare, git bisect]

2. 对超限情况进行分类

• 是否由代码变更导致？（新功能、重构、依赖项升级）
• 是否由基础设施变更导致？（新实例类型、配置变更）
• 是否由外部因素导致？（CDN 问题、DNS、上游依赖项）
• 是否属于测量异常？（测试环境问题、样本量）

3. 立即采取的措施

• 如果生产环境中发生 P1/P2 级超限，且已确认由代码导致：回滚或禁用功能标志
• 如果原因未知：不要立即回滚，先收集更多数据
• 在 [#performance / #incidents Slack 频道] 中通知相关人员，并提供：指标名称、当前值、预算目标、疑似原因

4. 解决问题

• 修复根本原因，不要只调整预算阈值
• 只有经过团队讨论并获得 [技术负责人 / 工程经理] 明确批准后，才能更改预算阈值
• 在 [性能日志 / 事件记录] 中记录超限情况

预算变更政策： 只有满足以下条件时，才能放宽预算阈值：（a）导致性能回归的功能具有可衡量的业务价值，且其价值超过性能成本；（b）变更经过审查并获得 [技术负责人] 批准。

---

性能审查周期

触发条件	操作
每个冲刺	审查 P95/P99 延迟趋势；标记任何逐渐恶化的情况
每季度	全面审查性能预算——更新基线、调整目标、审计工具
重大功能上线后	重新测量所有 Core Web Vitals 和 API SLO；更新基线
基础设施变更后	重新运行完整的合成测试套件；确认没有回归
依赖项升级后	运行包体积差异检查；确认体积没有意外增加

下次计划审查： [日期] 审查负责人： [姓名 / 职务]

---

质量检查

• 每个预算阈值都是具体数值，而不是范围或“TBD”
• 已定义前端（如适用）和后端目标，而不是只定义其中一项
• 已注明测量工具，并附上仪表板或配置文件的链接
• 已为至少一个关卡（构建时或部署时）配置 CI 强制检查
• 预算超限响应流程明确列出具体的 Slack 频道和负责人
• 预算阈值基于基线测量结果或合理目标，而不是凭空设定
• 已为关键用户旅程定义各自的目标，而不只是全局平均值

反模式

• 不要在测量当前基线前设置预算阈值——目标必须以实际情况为依据
• 不要只定义全局平均值——关键用户旅程需要单独的预算，因为它们的表现可能存在显著差异
• 不要省略 CI 强制检查——如果性能预算未在构建流水线中强制执行，就不会得到遵守
• 不要让超限响应流程缺少明确的负责人和升级渠道
• 不要只为一个环境设置预算——如果生产环境和预发布环境的目标不同，应分别记录