Core Web Vitals

追踪 Google 三个以用户为中心的指标：LCP、INP、CLS，保持在"良好"范围。

为什么

Core Web Vitals 是 Google 搜索排名算法用的指标，直接关联用户参与和转化。LCP（最大内容绘制）测主内容何时出现——超 2.5 秒用户觉页面慢。INP（交互到下一帧）测响应性——超 200ms 交互感滞后。CLS（累积布局偏移）测视觉稳定性——超 0.1 按钮在用户点击时跳，致误点和挫败。这些非抽象数字；是 2% 和 4% 转化率的差，Google 在搜索结果中惩罚慢页。追踪它们就是追踪页面是否快到用户愿留。

何时使用

在生产每页追踪（RUM——真实用户监控）。CI 中设预算（Lighthouse CI）阻 LCP/INP/CLS 超阈值部署。

如何做

1. 生产中用 RUM（真实用户监控）测
   - 用 web-vitals 库从真实用户收集 LCP、INP、CLS
   - 发到分析（Google Analytics 4、Datadog RUM、Vercel Analytics）
   - 看 75 百分位非平均——平均藏慢尾

2. CI 中用 Lighthouse 测
   - npx @lhci/cli autorun——每个 PR 跑 Lighthouse
   - 设预算: LCP < 2.5s、INP < 200ms、CLS < 0.1
   - 预算回退即 CI 构建失败（非已超——仅回退）

3. 优化 LCP（最大内容绘制）
   - LCP 元素通常是 hero 图或大文本块——找到它
   - 预加载 LCP 图: <link rel="preload" as="image" href="hero.jpg">
   - 用下一代格式（WebP、AVIF）服务图带响应尺寸
   - 移渲染阻塞脚本和 CSS；内联关键 CSS

4. 优化 INP（交互到下一帧）
   - 长任务（>50ms）阻交互——用 Performance Observer 找
   - 把长 JavaScript 拆小块；非紧急工作用 requestIdleCallback
   - 输入 handler 防抖；点击上别同步做重活

5. 优化 CLS（累积布局偏移）
   - 图和视频始终设宽高——预留空间不跳
   - 不在现有内容上方注入广告或横幅——预留其槽
   - 动画用 CSS transform 非触布局的属性（top、left）
   - web 字体用 font-display: optional 或 preload 防 FOIT/FOUT

示例

// 从真实用户收集 Core Web Vitals
import { onLCP, onINP, onCLS, onFCP, onTTFB } from "web-vitals";

function sendToAnalytics(metric) {
  fetch("/api/vitals", {
    method: "POST",
    body: JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      rating: metric.rating, // "good" | "needs-improvement" | "poor"
      page: location.pathname,
    }),
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

// Lighthouse CI 预算: lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "interaction-to-next-paint": ["warn", { "maxNumericValue": 200 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "first-contentful-paint": ["warn", { "maxNumericValue": 1800 }]
      }
    }
  }
}

常见问题

⚠仅 CI 中用 Lighthouse（合成）测非生产 RUM——CI 在快机器干净缓存上跑，报好分而慢手机 3G 真实用户见 5 秒 LCP。
⚠优化平均而非 75 百分位——平均 1.5 秒但 25% 用户见 4 秒，那些是跳走的用户；Google 按 p75 排名非平均。
⚠设 Lighthouse 预算但不让 CI 构建失败——预算是所有人无视的警告，性能每冲刺回退因无强制。
⚠给一个元素加 min-height 修 CLS 而其他图仍无尺寸加载——整体 CLS 略改但那些图加载时页面仍跳。

最佳实践

✓生产中用 RUM（web-vitals 库 → 分析）测看每页 75 百分位——这是 Google 见和真实用户经历的。
✓Lighthouse CI 预算设为错误（非警告）回退即构建失败——警告被无视，错误强制开发者合并前修回退。
✓每个图、广告槽和嵌入用显式宽高或 aspect-ratio 预留空间——这零运行时成本消除最常见 CLS 源。
✓用 <link rel="preload"> 预加载 LCP 元素（hero 图或字体）使浏览器在 HTML 中发现前开始取——这是单最高影响 LCP 优化。