Core Web Vitals是Google推出的Web性能核心指标，包括LCP、FID、CLS三个维度。我们团队在优化这些指标的时候，出了一次严重的故障，导致线上页面的性能指标急剧恶化。本文是这次故障的完整复盘，包括故障现象、排查过程、根本原因、修复方案以及经验教训。如果你也在做Web性能优化，希望这篇文章能给你一些警示和参考。

一、背景：为什么关注Core Web Vitals

先说说我们为什么关注Core Web Vitals。

2020年的时候，Google宣布将Core Web Vitals纳入搜索排名的因素。也就是说，网站的性能会直接影响搜索排名。这对于依赖搜索流量的网站来说，是一个非常重要的变化。

我们的网站主要流量来自搜索引擎，所以Core Web Vitals对我们来说至关重要。如果指标不达标，搜索排名会下降，流量会减少，直接影响业务。

Core Web Vitals包括三个指标：

  • LCP（Largest Contentful Paint）：最大内容绘制，衡量页面加载性能，要求2.5秒以内
  • FID（First Input Delay）：首次输入延迟，衡量交互响应性，要求100毫秒以内
  • CLS（Cumulative Layout Shift）：累积布局偏移，衡量视觉稳定性，要求0.1以内

我们之前的性能指标还不错，但是为了应对Google的更新，我们决定做一次全面的性能优化，把三个指标都提升到优秀水平。

优化项目进行了两周，我们做了很多工作：图片懒加载、代码分割、预加载关键资源、优化字体加载、减少第三方脚本等。优化之后，测试环境的指标确实有了明显提升。我们都觉得这次优化很成功，于是安排了上线。

但是没想到，上线之后出了大问题。

二、故障发生：指标急剧恶化

那是一个周二的上午，我们发布了性能优化的版本。发布之后，我们像往常一样监控线上的性能数据。

刚开始的一个小时，数据看起来还正常，LCP和FID都有改善。但是到了下午，我们发现数据开始不对劲了。

具体的现象是：

  • LCP从原来的2.3秒飙升到了5.8秒
  • CLS从原来的0.05飙升到了0.35
  • 页面的跳出率明显上升
  • 用户反馈页面加载慢、内容跳动

这个结果让我们所有人都震惊了。我们在测试环境测了很多次，指标都是改善的，为什么上线之后反而恶化了？

而且更糟糕的是，因为Google已经开始用Core Web Vitals作为排名因素了，我们的指标恶化可能会直接影响搜索排名。如果不尽快修复，损失会很大。

那天下午，我们整个团队都在紧急排查这个问题，一直搞到晚上，才终于找到了原因。现在回想起来，还是觉得惊心动魄。

三、排查过程：一步步定位问题

排查的过程非常曲折，我们走了很多弯路。下面说说我们是怎么一步步定位到问题的。

第一步：怀疑是缓存问题

刚开始我们以为是CDN缓存的问题。因为发布之后，旧的缓存可能还在，导致新老版本混合，出现了问题。

我们清理了CDN缓存，强制刷新了所有资源，但是问题没有解决。指标还是很差。

我们还检查了浏览器缓存，发现也不是缓存的问题。用户即使清了缓存，第一次访问还是很慢。

所以缓存问题的可能性被排除了。

第二步：怀疑是第三方脚本

接下来我们怀疑是第三方脚本的问题。因为我们在优化的时候，调整了第三方脚本的加载方式，从同步加载改成了异步加载。理论上这应该会提升性能，但是如果第三方脚本有问题，可能会影响页面渲染。

我们检查了所有的第三方脚本，发现有一个广告脚本的加载方式被我们改了。原来这个脚本是同步加载的，我们改成了异步加载。但是这个广告脚本会在页面加载完成之后，动态插入一个广告位，这个广告位没有设置固定的高度，导致插入的时候页面布局发生了偏移。

这就解释了CLS飙升的问题。但是LCP飙升的问题还是没有解释清楚。

我们先把广告脚本的加载方式改回了原来的同步加载，CLS确实有所改善，但是还是比原来差很多。而且LCP的问题完全没有解决。

所以第三方脚本只是部分原因，不是根本原因。

第三步：怀疑是图片优化的问题

然后我们开始怀疑图片优化的问题。我们在优化的时候，把所有图片都改成了懒加载，并且用了WebP格式。理论上这应该会提升LCP，因为首屏不需要加载所有图片。

但是我们发现了一个问题：我们把首屏的LCP图片也设置成了懒加载。这就导致首屏的主要内容图片被延迟加载了，浏览器要等JavaScript执行之后才开始加载这张图片，LCP自然就变慢了。

这个发现让我们很兴奋，觉得找到了LCP飙升的原因。我们把首屏的LCP图片改成了正常加载，并且加了preload。发布之后，LCP确实有所改善，从5.8秒降到了4.2秒，但是还是比原来的2.3秒差很多。

所以图片懒加载是一个原因，但是还不是全部原因。

第四步：发现根本原因

这时候我们有点焦头烂额了。常见的原因都排查了，但是LCP还是比原来差很多。

这时候团队里一个同学提出，我们是不是应该对比一下发布前后的页面，看看具体有什么不同。

我们用WebPageTest分别测了发布前后的页面，然后对比了瀑布图。这一对比，问题就暴露出来了。

我们发现，发布之后的页面，CSS文件的加载时间比原来长了很多。原来CSS文件是内联在HTML里的，发布之后我们把CSS抽成了外部文件，并且用了preload。但是preload的CSS文件，浏览器的优先级处理有问题，导致CSS加载被延迟了。

而且更严重的是，我们的CSS文件里用了@import引入了另一个CSS文件。这个@import的CSS文件要等第一个CSS文件下载解析之后才会开始加载，形成了一个加载链，大大延迟了页面的渲染。

原来内联CSS的时候，所有CSS都在HTML里，浏览器拿到HTML就能渲染。现在CSS变成了外部文件，还有@import的嵌套，导致渲染被阻塞了很久，LCP自然就变慢了。

而且CSS加载延迟还导致了CLS的问题。因为CSS没加载完的时候，页面是没有样式的，等CSS加载完之后，页面的布局会发生很大的变化，产生了大量的布局偏移。

找到根本原因之后，我们都松了一口气。原来是CSS加载策略的改动，导致了渲染阻塞，进而影响了LCP和CLS。

四、问题修复

找到原因之后，修复就简单了。

我们采取了以下修复措施：

1. 关键CSS内联

我们把首屏渲染需要的关键CSS重新内联到HTML里，确保浏览器拿到HTML就能立即渲染首屏。非关键的CSS还是用外部文件异步加载。

2. 去掉@import

我们把所有的@import都去掉了，改成了直接在HTML里用link标签引入。这样所有CSS文件可以并行加载，不会形成加载链。

3. 修复图片懒加载

首屏的LCP图片不用懒加载，并且加preload。非首屏的图片继续用懒加载。

4. 修复第三方脚本

广告脚本改回同步加载，并且给广告位设置固定高度，避免布局偏移。

5. 增加性能监控

我们加了更详细的性能监控，包括LCP、FID、CLS的实时监控，以及资源加载的瀑布图分析。出了问题能及时发现。

修复之后，我们先在测试环境反复测试，确认指标恢复正常了，然后紧急发布了修复版本。发布之后观察了几个小时，确认LCP回到了2.1秒，CLS回到了0.04，都比优化之前还要好。

五、根本原因分析

故障解决之后，我们做了一次深入的根本原因分析。

直接原因：CSS加载策略的改动（内联改外部+@import嵌套）导致了渲染阻塞，LCP变慢；CSS延迟加载导致布局偏移，CLS变大；首屏图片懒加载进一步恶化了LCP。

为什么测试环境没发现：测试环境的服务器在国内，网络延迟低，CSS文件加载快，所以问题不明显。线上用户的网络环境参差不齐，很多用户网络慢，CSS加载时间长，问题就暴露出来了。而且我们测试的时候主要看了实验室数据，没有看真实用户的field数据。

为什么没有做好灰度：我们这次发布是全量发布，没有做灰度。如果做了灰度，先让一小部分用户用新版本，就能及时发现问题，不会影响所有用户。

优化过度：我们为了优化性能，做了很多改动，但是有些改动反而适得其反。比如把内联CSS改成外部文件，理论上能利用缓存，但是对于首屏渲染来说，内联CSS其实更好。我们没有根据实际情况选择合适的方案，而是盲目地套用最佳实践。

六、我们采取的改进措施

这次故障给我们敲响了警钟。我们采取了一系列改进措施，防止类似的问题再次发生。

1. 性能优化要有数据支撑

以后做任何性能优化，都要有数据支撑。不能只看理论上的最佳实践，要在真实环境中测试，看实际效果。每个优化措施都要做A/B测试，确认有正向效果再全量发布。

2. 灰度发布

所有涉及性能的改动，都必须做灰度发布。先放1%的流量，观察指标没问题再逐步扩大。如果指标恶化，立即回滚。

3. 真实用户监控

加强真实用户的性能监控（RUM），不能只看实验室数据。实验室数据不能完全代表真实用户的体验，尤其是网络环境复杂的情况下。

4. 性能预算

建立性能预算机制。每个页面的LCP、FID、CLS都有明确的预算，任何改动都不能超过预算。如果超过了，必须说明原因并且优化。

5. 完善的测试用例

性能测试用例要覆盖各种网络环境，包括慢3G、4G、WiFi等。不能只在好的网络环境下测试。

七、Core Web Vitals优化的注意事项

结合这次故障的经验，总结一些Core Web Vitals优化的注意事项。

LCP优化注意事项：

  • 首屏的LCP元素不要懒加载
  • 关键CSS要内联，避免渲染阻塞
  • 用preload加载关键资源
  • 减少服务器响应时间
  • 优化图片，用合适的格式和尺寸

FID优化注意事项：

  • 减少JavaScript的执行时间
  • 拆分长任务，避免阻塞主线程
  • 用web worker处理耗时计算
  • 延迟加载非关键的JavaScript

CLS优化注意事项：

  • 给图片和视频设置固定的宽高
  • 给广告位和动态内容预留空间
  • 不要在已有内容上方插入内容
  • 字体加载用font-display: optional或者swap，避免FOIT

通用注意事项：

  • 不要盲目套用最佳实践，要根据实际情况选择
  • 每个优化都要测试实际效果
  • 做好灰度和监控
  • 关注真实用户的数据，不要只看实验室数据

八、写在最后

这次Core Web Vitals的故障，虽然过程惊心动魄，但是也让我们学到了很多。性能优化不是一件简单的事情，不是套用最佳实践就能做好的。每个网站的情况都不一样，需要根据实际情况选择合适的方案，并且用数据来验证效果。

而且性能优化是一个持续的过程，不是一次优化就一劳永逸的。需要持续监控、持续优化，才能保持良好的性能指标。

希望我们的这次故障复盘能给正在做Web性能优化的朋友一些参考和警示。如果你也遇到过类似的问题，欢迎在评论区交流讨论。

最后用一句话结束本文："性能优化没有银弹，只有数据驱动的持续改进。"愿每一个前端工程师都能打造出快速、流畅的用户体验。