前端性能回归如何定位？上线后突然变慢怎么办？

简化版

前端性能回归定位要先确认变慢范围，再定位指标和变更。常见流程是：看 RUM 监控确认哪些页面、地区、设备、浏览器变慢；看变慢指标是 LCP、INP、CLS、TTFB 还是资源加载；对比上线版本、资源体积、接口耗时、第三方脚本和错误率；必要时回滚或灰度止损。定位要把“什么时候开始变慢”和“那时发布了什么”对齐。

详细版

性能回归不是盲目优化，而是缩小范围。

现象	可能方向	排查工具
LCP 变慢	图片、首屏接口、CSS、TTFB	RUM、Network、Performance
INP 变差	长任务、事件处理、框架渲染	Long Tasks、Performance
CLS 变差	图片尺寸、广告、字体、异步插入	Layout Shift 记录
TTFB 变慢	服务端、CDN、网络	Server log、APM、CDN 日志

确认范围 → 锁定指标 → 对齐发布时间 → 对比资源/接口/脚本 → 复现 → 止损 → 修复验证

性能回归最怕凭感觉改代码，正确姿势是先把时间线、指标和版本对齐。

完整版教学

一、第一步先确认是不是回归

用户反馈“页面变慢”不一定代表全量回归。可能是某个地区网络问题、某个浏览器版本问题、某个接口偶发慢，也可能是样本量太小。

先看监控趋势：变慢是否持续、是否超过正常波动、是否集中在某些页面或用户分组。

二、按指标拆问题

不同指标变差，对应方向完全不同。

• LCP 变差：主内容出现慢，重点看 TTFB、首屏资源、LCP 元素加载和渲染。
• INP 变差：交互响应慢，重点看长任务、事件处理和渲染更新。
• CLS 变差：页面跳动，重点看尺寸占位、字体、广告和异步插入。
• TTFB 变差：首字节慢，重点看服务端、CDN、缓存和网络。

三、按维度缩小范围

RUM 数据要分组看：

维度	价值
页面路径	判断是否某个页面变慢
版本号	判断是否某次发布引入
设备等级	判断是否低端设备受影响
网络类型	判断是否弱网放大问题
地域/CDN 节点	判断是否边缘节点异常
浏览器	判断是否兼容性问题

如果只有低端 Android INP 变差，方向就不该放在 CDN；如果所有地区 TTFB 同时变差，就要看服务端和缓存。

四、对齐发布和资源变化

性能回归常和发布相关。要对比上线前后：

• JS/CSS 体积是否增长。
• 首屏 chunk 是否多了依赖。
• 图片是否变大或格式变化。
• 第三方脚本是否新增。
• 接口数量或瀑布顺序是否变化。
• 框架渲染次数是否增加。

npm run build
npx source-map-explorer dist/assets/*.js

如果构建产物变化明显，优先看依赖和拆包。

五、复现和止损

如果影响范围大，要先止损：回滚、关闭开关、下掉第三方脚本、降级非关键模块或切回旧资源。

复现时用和问题用户相近的条件：设备降速、网络限速、对应地区代理、清缓存和指定浏览器版本。

六、修复后要验证

修复不是本地看起来快就结束。要看：

• Lab 指标是否恢复。
• RUM 分位数是否回落。
• 错误率是否变化。
• 业务指标是否恢复。
• 是否引入新的视觉或功能问题。

七、常见误区与追问

• 误区：性能变慢就先压缩 JS。 不同指标对应不同瓶颈，TTFB 慢时压 JS 可能没用。
• 误区：只看平均值就能判断回归。 平均值可能掩盖低端设备或弱网用户的问题。
• 误区：本地无法复现就说明没问题。 真实用户环境复杂，要按设备、网络、地区和版本分组分析。
• 追问：如何快速止损？ 回滚、灰度关闭开关、禁用非关键第三方脚本或切换旧资源。
• 追问：怎么判断是前端还是后端问题？ 看 TTFB、资源下载、主线程任务和接口耗时分布。
• 追问：Source Map 对性能排查有什么用？ 可以把产物体积和执行栈映射回源码模块，定位新增依赖或重代码。

八、加强记忆

性能回归定位记成“范围、指标、版本、证据”。先确认谁慢，再看慢在哪个指标，然后对齐发布时间和变更，最后复现、止损、修复、线上验证。