Core Web Vitals 实操修复指南：先看真实用户数据，再按模板逐个修

这篇指南不讲理论，而是给出一套从 Search Console 真实数据出发的排查流程：按模板和设备分组找最差的 URL，锁定最弱指标再动手。文中附 LCP、INP、CLS 三项的达标线和对应修法，还有具体案例数字。

先看现场数据，别迷信实验室分数

• 达标标准是 LCP、INP、CLS 三项都在真实访问的第 75 百分位达到 Good，最弱的一项决定整体状态
• 实验室工具跑出来是绿的，不代表中端安卓手机上同一模板也合格；移动端和桌面端分开计分
• 先在 Search Console 分别读两份设备报告，再按模板（产品页、服务页、结账页、博客）给失败的 URL 分组，一个坏模板可能覆盖几百个页面
• 每组挑最差的 URL 用 PageSpeed Insights 测，记下现场数值而不是总分，作为修复前的基线

LCP 不达标：按服务器、首图、CSS 的顺序修

• 先把服务器响应时间（TTFB）压到 800ms 以内：全页缓存、CDN、优化数据库查询，HTML 晚到的话再小的图也没用
• 只给首屏大图设置 preload 和 fetchpriority=high，预加载所有图片和字体会让它们互相抢资源
• 用 AVIF/WebP 加 srcset 按屏幕发图，别让 390px 的手机下载 2400px 的文件；首屏大图绝不要懒加载
• 首屏 CSS 内联约前 14KB，其余 defer；非关键 JS 延后加载，只预加载首屏用到的那一个字体
• 案例：3.2MB 的 PNG 首图换成约 180KB 的响应式 WebP 并缓存 HTML 后，LCP 从约 4.8 秒回到 Good 区间

INP 不达标：砍长任务和第三方脚本

• HTTP Archive 数据显示计入 INP 后只有 43% 的网站能达标，响应速度是最常见的短板
• INP 统计整个访问过程中的点击、点按和按键，取最慢的交互而不是平均值；菜单、表单、结账、筛选器都算，hover 和滚动不算
• 在 Performance 面板找出超过 50ms 的长任务，把事件处理函数拆成每段 50ms 以内，让浏览器有机会先画出下一帧
• 逐个审计第三方脚本：聊天组件、标签管理器、热力图是惯犯，改到首次交互后或空闲时加载，没用的直接删
• 案例：一个商品筛选器每次点击重建 2000 行数据，导致 INP 全程超标；改成只更新变化的节点、输入加 debounce 即可

CLS 不达标：给晚到的内容预留空间

• 案例：侧边栏广告晚于正文加载，把文章顶移了 0.31，是 0.1 达标线的三倍多
• 布局偏移通常集中在少数几个模板上，而不是全站均匀分布，先按模板和设备查现场 CLS 再改样式
• 图片、广告、嵌入内容都要提前占位，避免横幅和弹窗晚到时把内容挤下去