2026年网站Core Web Vitals优化实战：LCP/INP/CLS全攻略

上个月我把一个客户站的LCP从4.8秒压到了1.7秒，流量涨了差不多30%。这事儿其实没很多人想的那么玄乎，核心就几步。

先说LCP。这个站最大的问题是首屏有张2.4MB的banner图，还是PNG格式。我把图转成WebP，体积直接掉到180KB。光这一步，LCP就减了1.5秒。接着给图片加了fetchpriority="high"，又用link rel="preload"提前加载首屏字体——这俩操作加起来又省了0.8秒。很多人忽略字体加载，其实中文字体文件动不动就几MB，不处理的话LCP直接被拖垮。

INP这个指标是2024年Google才正式推到Core Web Vitals里的，到2026年已经是排名因子了。说白了INP就是衡量用户点了按钮之后多久页面有反应。我那个站在移动端INP经常飙到400ms以上，查了一圈发现是第三方统计脚本在阻塞主线程。把统计代码改成延迟加载、用requestIdleCallback包裹之后，INP稳定在120ms左右。还有一个坑：事件委托绑在document上，导致每次点击都要遍历整个DOM树。改成直接在目标元素上绑事件，INP又降了30ms。

CLS相对好搞定。我的经验是给所有图片和广告位预设宽高，别让它们加载时才撑开布局。之前有个页面CLS 0.35，就是因为顶部banner没设高度，图片加载完整个页面往下跳一截。加个aspect-ratio或者直接写死width/height属性就解决了。Web字体引起的CLS也不少见，用font-display: swap配合预先测量字体的size-adjust属性基本能避免。

有个我自己用了两年多的调试方法：在Chrome DevTools的Performance面板里录一段操作，然后看Lighthouse和Web Vitals扩展的数据交叉比对。有时候Lighthouse给的分数很好看，但真实用户的CrUX数据很差，通常是因为Lighthouse模拟的是中端设备+3G网络，而你真实用户的网络环境更复杂。我建议直接看Search Console里的Core Web Vitals报告，那个是真实用户数据。

今年Google把INP的阈值从200ms收紧到了150ms，很多站一下子就不合格了。如果你的站也遇到这问题，可以先从第三方脚本下手——我处理过的站里，第三方代码平均贡献了40%的主线程阻塞时间。把不紧急的脚本全挪到空闲时执行，效果立竿见影。

标签： 网站优化 Core Web Vitals 性能优化