2026年3月Google又调了一次Core Web Vitals的阈值。LCP从2.5秒收紧到2.0秒，INP的"良好"线从200ms降到了150ms。我之前管的5个站里，有3个直接掉到了"需要改进"。
前一周看Search Console数据的时候懵了一下——自然流量两周跌了18%。翻了一下，发现是3月12号算法更新之后掉的。PageSpeed Insights一跑，LCP普遍在3.2-4.5秒之间，INP最差的一个页面到了380ms。
下面的方案是我花了三周多时间实测出来的，省得你再趟一遍坑。
优化前的数据
| 站点 | 类型 | LCP(前) | INP(前) | CLS(前) | 移动端评分 |
|---|---|---|---|---|---|
| 站点A | 企业官网 | 4.5s | 280ms | 0.15 | 42 |
| 站点B | 电商 | 3.8s | 380ms | 0.09 | 38 |
| 站点C | 博客 | 3.2s | 190ms | 0.22 | 55 |
| 站点D | SaaS | 4.1s | 320ms | 0.11 | 40 |
| 站点E | 资讯站 | 3.5s | 210ms | 0.18 | 48 |
LCP优化：从4.5秒到1.6秒
LCP大头的根因就三个：图片太大、首屏资源加载链太长、服务器响应慢。
1. 图片格式和尺寸
站点A的首屏是一张1920x1080的PNG背景图，原图2.1MB。浏览器下载这张图花了1.8秒，然后还要解码渲染。
改了三件事：转成AVIF格式，同画质下体积从2.1MB降到187KB，压缩比11倍；用 <picture> 标签做fallback，不支持AVIF的浏览器回退到WebP；针对移动端生成768px宽的版本。
<picture>
<source srcset="/img/hero.avif" type="image/avif">
<source srcset="/img/hero.webp" type="image/webp">
<img src="/img/hero.jpg" width="1920" height="1080"
loading="eager" fetchpriority="high">
</picture>fetchpriority="high"这个属性2026年所有主流浏览器都支持。告诉浏览器这张图优先加载，实测把LCP图片的加载优先级拉到了最高。
2. CDN和缓存
原来5个站全放在一台阿里云ECS上，没有CDN。静态资源TTFB在600-900ms之间。
上线Cloudflare CDN之后，静态资源TTFB降到80-120ms。配置了 Cache-Control: public, max-age=31536000, immutable，带hash的静态资源永久缓存。HTML页面设置 Cache-Control: public, max-age=3600, stale-while-revalidate=86400。
stale-while-revalidate比较关键——用户访问时先给缓存版本，后台异步刷新。实测把首次访问延迟降了约200ms。
3. 关键CSS内联
站点D的页面打开后先白屏0.6秒，因为浏览器要等一个180KB的CSS文件加载完才开始渲染。
把首屏渲染必须的CSS提取出来（约8KB），直接内联到 <head> 里。剩下的CSS用preload异步加载，不影响首屏渲染。这个改动把站点D的LCP从4.1秒拉到了1.8秒。
<style>/* 首屏关键CSS */</style>
<link rel="preload" href="/styles/full.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">4. 资源预加载
站点B的LCP元素是一张产品主图，但这张图被一个懒加载库延迟了。问题是这张图在首屏，根本不需要懒加载。去掉了首屏所有图片的loading="lazy"。
字体文件加了preload，因为字体不加载完浏览器不会渲染文字，延迟直接加到LCP上：
<link rel="preload" href="/fonts/noto-sans.woff2"
as="font" type="font/woff2" crossorigin>INP优化：从380ms到120ms
INP衡量的是用户交互后到浏览器实际渲染响应的时间。站点B的INP最差，380ms。
问题定位
用Chrome DevTools的Performance面板录了一段用户操作。发现点击"加入购物车"按钮后，触发了一个80ms的同步DOM操作，同时发了一个XHR请求获取库存，回调里又做了60ms的DOM更新。两段长任务之间还夹了一个第三方统计脚本的定时器，占用了45ms主线程。加起来主线程被占用了近200ms，加上渲染管线延迟，总INP到了380ms。
解决方案
把DOM更新拆开。点击后先更新UI（切换按钮状态、数字+1），控制在30ms以内。库存查询放 requestIdleCallback 里，不跟UI抢主线程：
button.addEventListener('click', () => {
// 立即更新UI，控制在30ms内
updateCartUI();
// 后台查库存
requestIdleCallback(() => {
fetchInventory().then(updateStockBadge);
}, { timeout: 2000 });
});第三方统计脚本的初始化移到 window.onload 之后，用 requestIdleCallback 包裹。改完之后站点B的INP从380ms降到120ms。
另一个大收益来自CSS containment。给页面中不依赖布局计算的大区块加上 contain: layout style，减少重排范围：
.product-grid {
contain: layout style;
}站点D加了这个属性后，INP从320ms降到了145ms。
CLS优化：从0.22到0.03
站点C的CLS最差，0.22。原因是文章里的图片没有设宽高，插入广告位也没有预留空间。
所有 <img> 标签强制加上 width 和 height 属性。配合CSS的 height: auto，浏览器自动按比例计算高度：
img {
max-width: 100%;
height: auto;
}广告位用 min-height 预留空间：
.ad-slot {
min-height: 250px;
}字体加载导致的CLS用 font-display: swap 配合 size-adjust 解决。size-adjust: 105% 让fallback字体的度量值接近自定义字体，切换时页面布局基本不动。
@font-face {
font-family: 'Noto Sans';
src: url('/fonts/noto-sans.woff2') format('woff2');
font-display: swap;
size-adjust: 105%;
}优化后的数据
| 站点 | LCP | INP | CLS | 移动端评分 | LCP变化 | INP变化 |
|---|---|---|---|---|---|---|
| 站点A | 1.6s | 105ms | 0.02 | 92 | -64% | -63% |
| 站点B | 1.4s | 120ms | 0.04 | 89 | -63% | -68% |
| 站点C | 1.2s | 95ms | 0.03 | 94 | -63% | -50% |
| 站点D | 1.8s | 145ms | 0.03 | 88 | -56% | -55% |
| 站点E | 1.5s | 110ms | 0.02 | 91 | -57% | -48% |
全部拉到绿线。
流量变化：优化上线两周后，5个站的日均自然搜索流量从优化前的12,400涨到15,100，涨了约22%。站点B（电商）涨得最多，从日均4,200到5,500，涨了31%。
几点经验
先跑数据再动手。不是所有的慢都是图片造成的。站点D的瓶颈在CSS，站点B的瓶颈在JS。不看数据直接上CDN可能白花钱。
LCP和INP经常互斥。为了提高LCP，你把资源往前提；但加载太多资源会挤占主线程，INP反而变差。平衡点：首屏只加载渲染必需的资源，其他全部延迟。
2026年的新坑：AI聊天插件。有两个站加了AI客服浮窗，把INP拉高了60-80ms。这些插件的JS在主线程上持续运行。如果必须加，至少用Web Worker把逻辑丢到后台线程。
AVIF已经可以全量上了。2026年Edge、Chrome、Firefox、Safari 16.4+全兼容AVIF。唯一的例外是部分旧版安卓WebView，用 <picture> 回退到WebP就行。
如果现在你的站还在"需要改进"，先把Search Console里的Core Web Vitals报告拉出来看具体哪些URL有问题，跑一遍Lighthouse，然后按LCP→INP→CLS的顺序逐个修。三周时间基本够用。
标签： 网站优化 Core Web Vitals seo 性能优化 2026
还木有评论哦，快来抢沙发吧~