性能监控深度解析：Web Vitals与Performance API实战

一句话概括

性能监控是前端工程化的”血压计”——通过采集 LCP、INP、CLS 等 Core Web Vitals（FCP 属于广义 Web Vitals，非 Core 级），结合 Performance API 和自定义测速点，把”页面快不快”从感受变成可量化、可报警、可优化的数据。

核心知识点

1. Core Web Vitals 三大核心指标

官方定义的 Core Web Vitals 只有三项：LCP、INP、CLS。FCP 属于广义 Web Vitals（辅助指标），不是 Core 级，下面一并列出供对比。

指标	含义	优质标准	测量的是	级别
LCP	最大内容绘制	≤ 2.5s	“页面看起来加载完了吗”	Core
INP	交互到下次绘制	≤ 200ms	“点击后需要多久才响应”	Core
CLS	累计布局偏移	≤ 0.1	“页面有没有突然跳来跳去”	Core
FCP	首次内容绘制	≤ 1.8s	“用户最早看到内容的时间”	广义 Web Vitals

INP 在 2024 年 3 月正式取代 FID，因为 FID 只测量首次交互延迟，INP 测量整个生命周期中最慢的交互。

2. LCP 的动态采集

LCP 不是静态值——它会随着更大元素的出现而更新，直到用户交互或页面隐藏才最终确定：

const lcpObserver = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  // LCP 在用户交互前会持续更新，取最后一个
  console.log('LCP 候选:', lastEntry.startTime, lastEntry.element?.tagName);
});

lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

// 上报时机：页面隐藏时取最终值
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    // 从 performance API 取最后记录的 LCP
    lcpObserver.disconnect();
  }
});

为什么不能直接用 performance.timing？因为 LCP 是动态更新的，performance.timing 只记录了导航的静态时间点。

3. CLS 的会话窗口策略

CLS 不是简单累加（否则长时间打开的页面 CLS 无限大），而是使用会话窗口：

let clsValue = 0;
let sessionScore = 0;
let sessionStart = performance.now();

const clsObserver = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) { // 排除用户交互导致的布局偏移
      const now = performance.now();
      // 新窗口：间隔 5s 或首次记录
      if (now - sessionStart > 5000 && sessionScore > 0) {
        clsValue = Math.max(clsValue, sessionScore);
        sessionScore = 0;
        sessionStart = now;
      }
      sessionScore += entry.value;
    }
  }
});

clsObserver.observe({ type: 'layout-shift', buffered: true });

最终 CLS = 所有窗口中得分最大者。因为 CLS 是累加的，最新规范在 Chrome 中已经改为窗口最大值。

4. Performance API 的多层级能力

// Navigation Timing - 页面加载各阶段耗时
const [nav] = performance.getEntriesByType('navigation');
console.log({
  DNS: nav.domainLookupEnd - nav.domainLookupStart,        // DNS 查询耗时
  TCP: nav.connectEnd - nav.connectStart,                   // TCP 连接耗时
  TTFB: nav.responseStart - nav.requestStart,               // 首字节时间
  Download: nav.responseEnd - nav.responseStart,            // 内容下载耗时
  DOMContentLoaded: nav.domContentLoadedEventEnd - nav.startTime,
});

// Resource Timing - 所有资源的加载详情
const resources = performance.getEntriesByType('resource');
const slowestScript = resources
  .filter(r => r.initiatorType === 'script')
  .sort((a, b) => b.duration - a.duration)[0];

// Long Tasks - 阻塞主线程 > 50ms 的任务
const ltObserver = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.warn('长任务:', entry.duration + 'ms');
    }
  }
});
ltObserver.observe({ type: 'longtask', buffered: true });

5. 自定义测速：performance.mark / measure

// 业务埋点：测量搜索到首条结果渲染的耗时
performance.mark('search:start');
await fetch('/api/search?q=手机');
performance.mark('search:apiDone');

// 渲染第一条结果后
performance.mark('search:firstRendered');

// 自动计算耗时
performance.measure('search:toFirstResult', 'search:start', 'search:firstRendered');
const measure = performance.getEntriesByName('search:toFirstResult')[0];
console.log('搜索到首条结果:', measure.duration, 'ms');

其实你每天都在用

• Chrome DevTools Performance 面板看到的那根红色的 LCP 线：那是浏览器内置的性能测量，和你的监控 SDK 采集的是同一套 API
• Lighthouse 跑分里的 Performance 分数：本质上就是对 Web Vitals 各项指标的加权评分
• 图片懒加载导致 CLS 飙升：图片没有设 width/height 或使用 aspect-ratio 时，加载后撑开布局导致页面跳动
• content-visibility: auto 提升长列表性能：浏览器只渲染可视区域，大幅减少 FCP/LCP
• Nginx 开启 gzip/brotli：直接影响 responseStart - requestStart 的内容下载耗时

常见误解（FAQ）

❌ 误区 1：「LCP 就是页面最大的那部分加载完的时间」

LCP 测量的是视口中最大的可见元素。如果一个全屏背景图在第二屏（不可见），它不算 LCP。如果用户快速滚动走了，LCP 可能会提前冻结。LCP 在用户首次交互（点击、滚动、键盘输入）时立即冻结。

❌ 误区 2：「用 performance.timing.loadEventEnd 就够衡量性能了」

loadEventEnd 是 2010 年代的指标——它衡量”所有资源加载完毕”，包括底部的埋点脚本、分析 SDK。现代 Web App 的用户感知加载完成远早于此。LCP 和 FCP 才是真正对应用户感知的指标。

❌ 误区 3：「PerformanceObserver 和 getEntries() 可以互换」

getEntries() 返回当前快照，后续不会更新。LCP、CLS 这种动态指标必须用 PerformanceObserver 实时监听。而且浏览器 Performance Buffer 有限（约 150-250 条），getEntries() 可能丢失早期条目。

❌ 误区 4：「INP 就是 FID 的改名」

FID 只测首次输入延迟，INP 测全生命周期中最慢的交互（取 98 分位数）。一个页面 FID 可能很好（首次点击很快），但 INP 可能很差（第 10 次点击时因为内存碎片化导致响应变慢）。INP 更真实反映了用户长期使用体验。

一句话总结

性能监控的目标不是”集齐所有指标数据”，而是用几个关键数字告诉你”用户到底觉得快不快”——LCP 代表”能不能看得到”，INP 代表”能不能点得动”，CLS 代表”会不会跳得烦”。