2026 年 9 月一个客户周五下午发版，晚上收到告警，移动端 LCP 从 2.3 秒涨到 4.1 秒。我们用半小时定位到原因，是先回滚再查，不是边查边等。
第一步：先确认是真变慢
排除网络波动和测试误差。同一时间用同一个工具测两次，看是否稳定。
看监控曲线。如果所有页面一起变慢，可能是 CDN 或者服务器的问题；如果只有某类页面，大概率是这次发版的内容。
再看真实用户数据。CrUX 有延迟，RUM 更及时，有自建监控的这时候才能看出影响面。
第二步：先回滚
确认是发版导致的，第一动作是回滚，不是查原因。
回滚之后用户先恢复正常，然后你在本地慢慢查。这个顺序很多人搞反，结果线上慢了两小时。
回滚前把版本号和变更记录存好，查的时候要用。
第三步：看变更清单
对比发布前后的资源清单：新增了哪些 JS、图片、字体、第三方脚本，哪些文件体积变大了。
打包产物通常有 manifest，前后一对比，涨了多少一目了然。
第三方脚本尤其要查。这次的问题就是一个营销团队加的 A/B 测试脚本，体积 260KB，还在 head 里同步加载。
第四步：对比瀑布图
发布前后各抓一份 HAR，放在一起对比。
看关键资源的请求时间、顺序、优先级。我们这次看到 LCP 图片的请求被一个新脚本挤到了后面，开始时间晚了 1.2 秒。
这种问题不看瀑布图根本发现不了，因为文件本身没变。
我们遇到最多的四种回归
第一种，新加的第三方脚本。占了大概一半。
第二种，图片没压缩就上传。设计师给的原图直接传上去，一张三兆。
第三种，CSS 体积变大。组件库升级，样式文件翻倍。
第四种，缓存策略被改。发版时改了缓存头，所有静态资源重新下载。
回滚之外的补救
回滚之后要做两件事：把这次的回归写进复盘，说明是哪个提交、为什么没被发现；再补一条监控，让同类问题下次能被提前拦住。
如果一时修不好，还有临时方案：把新脚本改成异步加载、图片先压缩替换、给关键资源加 preload。
临时方案只能顶几天，别当长期解。我们见过一个站用临时方案撑了半年，最后谁也说不清当初为什么那么改。
一个预防措施
发版前跑一次性能对比，把核心页面的三个指标和上一个版本比，超过 10% 就不发。
这个检查放进 CI，几分钟能跑完。比上线后救火便宜太多。
发版窗口也有讲究。别在周五下午发大改动，出问题没人加班查。这条是我们用两次事故换来的。
元析智能
为软件公司做 SEO 和 GEO 优化