Core Web Vitals 修复顺序：先看真实用户数据，按模板逐个修

这篇指南强调别追实验室满分，而是以 Search Console 的真实用户数据为准，按模板和设备分组，先修最弱的那个指标。文章给出 LCP、INP、CLS 三条修复路线的具体步骤和工具用法，还附了三个真实案例：3.2 MB 的 hero 图、重渲染 2000 条商品列表的筛选器、把文章挤走 0.31 的侧栏广告。

先定优先级：最弱的指标说了算

• 一组 URL 只有在 LCP、INP、CLS 三项都达到 Good（按真实访问的第 75 百分位）才算通过，两项达标救不了第三项
• LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1；数据来自 Chrome 用户 28 天滚动窗口，移动端和桌面端分开计分
• 实操原则：只修已经不达标的指标，别把一周时间花在打磨已经及格的那项上
• 做电商的话，先处理商品页、分类页和结账页，再碰一次性的落地页

改代码前先做四步排查

• 在 Search Console 里分别读移动端和桌面端报告，桌面通过常常掩盖移动失败
• 把不达标的 URL 按模板分组：商品页、服务页、博客、结账，一个坏模板可能覆盖几百个 URL
• 每组挑最差的代表页跑 PageSpeed Insights，记下真实字段值而不是总分，锁定基线数字
• 用中端手机节流配置录 Performance trace，找到最大的元素或长任务，每个模板写一条具体假设再动手

LCP：先查服务器，再查 hero 图

• 按顺序排查：服务器响应（TTFB 争取 800 毫秒以内，加全页缓存和 CDN）→ hero 文件 → 阻塞渲染的 CSS/JS
• 只给 hero 图设 fetchpriority=
• hero 图用响应式 AVIF/WebP 配 srcset，别让 390px 的手机下载 2400px 的图；hero 绝不能懒加载
• 首屏 CSS 内联约前 14 KB，其余 defer；案例：3.2 MB PNG 换成 180 KB WebP 并缓存 HTML 后，LCP 从约 4.8 秒进入 Good 区间

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

• HTTP Archive 数据显示计入 INP 后只有 43% 的网站整体达标，响应性是最常见的短板
• INP 记录整个访问过程中最慢的交互而非平均值，菜单、表单、结账、商品筛选都算，hover 和滚动不算
• 在 Performance 面板找超过 50 毫秒的长任务，把事件处理拆成小块让浏览器能先绘制下一帧
• 逐个审计第三方脚本（聊天组件、tag manager、热力图），推迟到首次交互或空闲时加载，删掉不用的；用动态 import 拆 bundle，别整页重绘
• 案例：商品筛选器每次点击重渲染 2000 条数据导致 INP 超标，改成只更新变化的节点即可

CLS：布局偏移集中在少数模板上

• 案例：侧栏广告晚加载把文章挤动 0.31，约为 0.1 及格线的三倍，一个位置造成几乎全部损害
• 偏移通常集中在少数几个模板而不是均匀分布，改样式前先按模板和设备看字段 CLS 数据
• 给图片、广告、嵌入内容预留空间，避免晚注入的横幅把内容顶下去