Core Web Vitals 优化实战：LCP、INP、CLS 测量、修复与 CI 门禁

一、指标目标与适用边界

Core Web Vitals 用 LCP 衡量最大内容可见时间、INP 衡量交互响应、CLS 衡量意外布局移动。优化以真实用户第 75 百分位为主，实验室工具用于复现和定位。LCP 良好目标是 2.5 秒以内，INP 200 毫秒以内，CLS 0.1 以内。

不要把一次 Lighthouse 高分代表全站体验。页面模板、设备、地区、登录态、缓存和第三方脚本都要分层观察，样本不足时明确标注而不是过早下结论。

真实浏览器 RUM → 页面/设备/地区聚合 → P75 → 产品 SLO
      ↑                                      ↓
DevTools/Lighthouse ← 固定复现场景 ← CI 性能预算

二、接入真实用户监控

web-vitals 在浏览器采集指标，sendBeacon 在页面结束时也有较高送达率。只上传页面模板、构建版本和低基数设备信息，不发送完整查询串、输入内容或个人标识。

npm install web-vitals

import { onCLS,onINP,onLCP,type Metric } from 'web-vitals'
function report(m:Metric) {
 const body=JSON.stringify({name:m.name,value:m.value,rating:m.rating,id:m.id,path:location.pathname})
 navigator.sendBeacon('/rum/web-vitals',body)
}
onLCP(report); onINP(report); onCLS(report)

三、建立可重复实验室基线

固定 Chrome、CPU 节流、网络、视口、缓存和测试数据。CI 噪声大时连续运行 3～5 次使用中位数，并保存 trace 与构建 SHA；不要用几毫秒差异阻断发布。

npm install -D lighthouse
npx lighthouse https://example.test/article \
 --chrome-flags='--headless=new' --preset=desktop \
 --output=json --output-path=artifacts/article-lighthouse.json
sha256sum artifacts/article-lighthouse.json

四、LCP：拆分服务器、发现、下载和渲染

先在 trace 中确认 LCP 元素，再分解 TTFB、资源发现延迟、下载和渲染延迟。首屏主图不要 lazy-load；提供响应式尺寸和显式 fetchpriority。预加载过多会抢占 CSS 与字体。

<link rel="preload" as="image" href="/hero-1280.avif"
 imagesrcset="/hero-640.avif 640w, /hero-1280.avif 1280w"
 imagesizes="(max-width:768px) 100vw, 1200px" fetchpriority="high">
<img src="/hero-1280.avif" srcset="/hero-640.avif 640w, /hero-1280.avif 1280w"
 sizes="(max-width:768px) 100vw, 1200px" width="1280" height="720" fetchpriority="high" alt="文章主题图">

五、INP：拆分长任务并及时反馈

在 Performance 面板找到 interaction，检查事件处理、样式计算、布局和绘制。纯计算移到 Worker，大列表虚拟化，非关键任务延后。点击后先同步更新按钮状态，再异步执行重工作。

async function renderRows(rows) {
 const size=200
 for (let i=0;i<rows.length;i+=size) {
   renderChunk(rows.slice(i,i+size))
   await new Promise(resolve=>setTimeout(resolve,0))
 }
}
searchInput.addEventListener('input',debounce(e=>worker.postMessage({type:'filter',query:e.target.value}),120))

六、CLS：为异步内容保留空间

图片和视频写 width/height 或 aspect-ratio；广告和推荐位提前保留空间；动画使用 transform 与 opacity。字体选择度量接近的后备字体，必要时使用 size-adjust 降低替换位移。

.article-cover{aspect-ratio:16/9;width:100%;object-fit:cover}
.ad-slot{min-height:250px;contain:layout paint}
.avatar{width:40px;height:40px;border-radius:50%}
@font-face{font-family:'Site Sans';src:url('/fonts/site.woff2') format('woff2');font-display:swap;size-adjust:100%}

七、治理第三方脚本与水合

为每个第三方脚本记录所有者、业务价值、主线程耗时和撤销方法。非必要分析脚本在同意后且空闲时加载。服务端渲染避免水合前后 DOM 不一致，大组件按交互拆包，但首屏关键内容不应过度懒加载。

<script type="module">
requestIdleCallback(()=>{
 if(window.analyticsConsent) import('/analytics-loader.js')
},{timeout:3000})
</script>

八、建立 CI 性能预算

CI 中 TBT 只是 INP 的实验室代理，不等于真实 INP。除 Lighthouse 指标外还限制 JS、CSS 和图片体积，并按页面模板设置预算；开发机器和 CI 使用同一构建产物。

{"ci":{"collect":{"url":["http://localhost:4173/","http://localhost:4173/articles/demo"],"numberOfRuns":3},"assert":{"assertions":{"largest-contentful-paint":["error",{"maxNumericValue":2500}],"cumulative-layout-shift":["error",{"maxNumericValue":0.1}],"total-blocking-time":["warn",{"maxNumericValue":300}]}}}}

npm ci
npm run build
npm run preview -- --host 0.0.0.0 &
npx wait-on http://localhost:4173
npx lhci autorun

九、灰度验证与回滚

一次只修改一个主要变量，在同一场景比较中位数并检查其他指标、错误率和转化率没有退化。发布携带构建版本进入 RUM，先小流量灰度；现场数据改善后再扩大。

回滚阈值在发布前量化。
缓存命中和冷启动分别观察。
真实数据至少覆盖一个业务周期。
回归按页面模板和设备定位。

十、排障与验收清单

先用现场 P75 确认范围和开始版本，再在固定环境复现并保存 trace、网络瀑布和 LCP 元素。修复后比较实验室中位数，最后以灰度现场数据验收。

LCP 元素可识别且资源发现路径清晰。
INP 长任务能定位到具体处理器。
CLS 每个位移来源有对应 DOM。
CI、RUM 和构建版本能够关联。

总结

Core Web Vitals 优化是测量系统而不是一次冲分。用 RUM 确认用户问题，用 trace 定位 LCP、INP、CLS 的阶段，用 CI 阻止回归，再用灰度现场数据验证收益，才能持续改善真实体验。