性能监控、告警和防回归怎么做

维护说明

• 这页统一引用 性能公共素材 的防回归口径。
• 如果要改治理闭环讲法，优先改素材页。

一句话先定性

性能优化如果只做一次，不做监控和防回归，很容易过几周又回到原点，所以我会把它当成一个持续治理闭环。

30 秒版本

如果面试官问性能怎么做监控和防回归，我一般会讲三件事。第一，先把关键指标接进监控，比如 LCP、INP、CLS、接口耗时和错误率；第二，按页面和核心链路做阈值告警，不让问题只能靠用户反馈；第三，把这次优化沉淀成发布后校验和长期看板，避免同类问题反复出现。

1 分钟版本

我一般会把性能治理分成三个环节：采集、告警、防回归。采集层面先明确核心指标，比如 LCP 看首屏、INP 看交互、CLS 看稳定性，必要时补 TTFB、接口耗时和资源体积。

告警层面我不会只盯全站平均值，而会更关注核心页面、核心路径和 p75 这种更接近用户体感的口径。这样一旦某次发版把核心页面性能拉差，能更快发现。

防回归层面我会做两件事：一是把关键指标放进发布后观察清单，二是把这次优化抽成团队规则，比如首屏资源不要再无脑进主包、图片必须预留尺寸、重列表必须优先考虑虚拟化。这样性能才不会变成一次性的救火。

2 到 3 分钟版本

如果面试官问性能监控、告警和防回归怎么做，我一般会把它理解成性能治理的后半段。因为优化动作本身只是开始，真正难的是怎么保证问题后面不反复出现。

第一步是监控。我会先把关键指标接进统一监控链路里，而不是等用户说慢才知道慢。最常用的一般就是 LCP、INP、CLS、TTFB，再加接口耗时、资源大小、错误率这些辅助指标。这里我会特别强调口径，通常不会只看平均值，而更关心 p75、核心页面和核心路径的数据。因为性能问题很多时候不是全站普遍差，而是集中在少数关键场景。

第二步是告警。我的经验是，告警不能太泛，否则很快就没人看了。所以我更倾向于给核心页面和关键指标设阈值，比如某个主链路页面的 LCP 连续一段时间超过阈值，或者某次发版后 INP 明显抬升。这种告警最好还能带上版本、页面路径和设备维度，方便快速定位。

第三步是防回归。这里我通常会做三类事情。第一类是发布后观察，也就是每次重要发版之后重点盯核心页面和指标变化，不等用户反馈。第二类是规则沉淀，比如主包体积预算、图片尺寸预留、长列表虚拟化、重计算延后执行，这些最好变成团队共识。第三类是经验回流，把这次问题的根因和判断方式写下来，让下次排查路径更短。

如果团队工程化能力更强一点，我还会继续往前做，比如把包体积、关键页面 Lighthouse 或 Web Vitals 校验接进 CI，至少在合并前先把明显风险暴露出来。虽然这不能完全替代线上监控，但能把一部分回归提前拦下来。

所以如果让我总结，我会说性能治理真正闭环是“采集 - 告警 - 观察 - 防回归”。能把这四步讲清楚，面试官会更容易相信你做过的是持续治理，而不是一次性优化。

如果面试官追问“为什么你强调 p75”

因为平均值太容易被极端样本稀释掉，不能很好反映大多数用户真实体验。p75 更适合用来做性能治理和告警基线。

如果面试官追问“告警怎么避免噪音太多”

我不会什么都告警，而是优先盯核心页面、核心链路和最关键的指标，而且会带上持续时间和阈值条件，避免偶发抖动就反复报警。

最后一句收尾

所以性能优化真正做完，不是页面快了一次，而是要把监控、告警和防回归补齐，让它后面不容易再慢回去。