Core Web Vitals怎么优化？从不及格到全绿的实操记录

上个月帮一个客户做网站体检，Google PageSpeed Insights的移动端得分只有23分——LCP 6.8秒、CLS 0.42、INP 380ms，三项Core Web Vitals全红。客户说"我网站看着挺快的啊"，我说"那是你自己电脑缓存了，新用户首次访问不是这个体验"。花了两周优化到87分，三项全绿。过程记录如下。

先搞清楚三个指标到底是什么

LCP（Largest Contentful Paint）：最大内容元素渲染完成的时间。简单说就是用户打开页面后，看到"主要内容"要等多久。Google要求2.5秒以内算"好"。

CLS（Cumulative Layout Shift）：页面加载过程中元素的累计位移量。就是你正准备点一个按钮，结果上面的图片加载出来把按钮挤下去了，你点到了广告。Google要求0.1以内算"好"。

INP（Interaction to Next Paint）：用户操作后页面响应的速度。点击按钮、输入文字后，页面多久给出反馈。Google要求200ms以内算"好"。

LCP优化：最大的一张图决定生死

我那个客户的LCP元素是首屏的一张Banner图，原图4.2MB的JPEG。光这一张图就让LCP飙到6.8秒。我的操作步骤：

第一步，把图片转成WebP格式，从4.2MB压到680KB。第二步，加上srcset属性，手机端加载小尺寸的版本（750px宽），不用加载桌面端的2000px大图。第三步，给图片加上fetchpriority="high"属性，告诉浏览器"这张图很重要，优先加载"。三步做完，LCP从6.8秒降到了1.9秒。

如果你的LCP元素不是图片而是文字块，检查一下是不是有渲染阻塞的CSS或JS。把关键CSS内联到HTML里、非关键JS加上defer或async属性，能显著减少LCP。

CLS优化：给所有动态元素预留空间

CLS高的常见原因：图片/视频没有设置宽高、广告位动态加载、字体FOUT（Flash of Unstyled Text）。我那个客户的问题是三个都有。

图片问题最好解决——给img标签加上width和height属性，或者用CSS的aspect-ratio。这样浏览器在图片加载之前就知道要留多大空间，不会出现加载完之后的布局跳动。

广告位的问题稍微复杂。我们用了CSS给广告容器预留固定高度，广告加载完之后容器大小不变。如果广告尺寸不确定，至少预留一个最大可能的高度。

字体问题用font-display: swap解决。这个属性让浏览器先用系统字体显示文字，等自定义字体加载完再替换。为了避免替换时的文字跳动，我用了size-adjust属性让系统字体和自定义字体的大小尽量一致。

INP优化：减少主线程阻塞

INP是2024年才替代FID成为Core Web Vitals指标的。它测的不是"第一次交互"，而是"所有交互中最慢的一次"。我那个客户的INP问题出在一个表单组件上——用户输入文字时，每次按键都触发一个搜索API调用，同时在主线程上做了DOM遍历和重渲染。

解决方法：加防抖（debounce），用户停止输入300ms后才发请求；把DOM操作移到requestIdleCallback里执行；搜索结果用虚拟列表渲染，不一次性插入所有结果。改完之后INP从380ms降到了120ms。

一个容易被忽略的优化：服务器响应时间

TTFB（Time to First Byte）虽然不是Core Web Vitals的直接指标，但它影响所有其他指标。如果你的服务器响应要1秒，那LCP再怎么优化图片也很难低于2秒。我那个客户用的是某国内小厂的虚拟主机，TTFB平均800ms。换了一个轻量云服务器+LiteSpeed之后，TTFB降到了120ms。

优化工具推荐

PageSpeed Insights：免费，看整体得分和具体建议。Chrome DevTools的Performance面板：看详细的加载瀑布图和主线程活动。Web Vitals Chrome插件：实时显示当前页面的三个指标。DebugBear或者SpeedCurve：持续监控，每天自动测一次。

最后说一句：Core Web Vitals的分数不是一次性的工作。每次加新功能、换主题、装插件，都可能影响这些指标。建议每个月用PageSpeed Insights检查一次，发现问题及时处理。

标签： Core Web Vitals 网站优化 LCP CLS INP PageSpeed