Core Web Vitals 是什么？LCP、INP、CLS 怎么优化？

详细解析#

三个核心指标#

INP 在 2024 年 3 月取代了 FID。评估时取真实用户数据的第 75 百分位，也就是至少 75% 的访问达到"良好"，这个页面才算达标。

CLS 的算法：单次布局偏移的分数 = 影响比例 × 距离比例；相邻偏移间隔不到 1 秒的归为同一个会话窗口（最长 5 秒），CLS 取分数总和最大的那个窗口。

其他常用指标：FCP（首次内容绘制）、TTFB（首字节时间），以及实验室指标 TBT（总阻塞时间，常作为 INP 在实验室中的参考）。

实验室数据与真实用户数据#

测量方法：用 web-vitals 库，或者直接用 PerformanceObserver 监听 largest-contentful-paint、layout-shift 等性能条目。

import { onCLS, onINP, onLCP } from 'web-vitals'

function report(metric) {
  // rating 的取值是 'good'、'needs-improvement' 或 'poor'
  const body = JSON.stringify({ name: metric.name, value: metric.value, rating: metric.rating })
  navigator.sendBeacon('/analytics', body)
}

onCLS(report)
onINP(report)
onLCP(report)

优化 LCP#

• 缩短 TTFB：CDN、服务端缓存，减少重定向
• 让 LCP 资源尽早被发现和加载：LCP 图片直接写在 HTML 里并加上 fetchpriority="high"；写在 CSS 背景里或由 JS 渲染的图片，用 preload 提前加载（见资源提示）
• 首屏大图不要懒加载：loading="lazy" 会推迟它的加载（见图片懒加载）
• 压缩图片：使用 WebP、AVIF 等格式，按显示尺寸提供图片
• 减少阻塞渲染的 CSS 和 JS：关键 CSS 内联，非关键 JS 加 defer
• 考虑 SSR：首屏 HTML 直接带上内容，不用等 JS 下载执行完才渲染

优化 INP#

一次交互的延迟由三部分组成：输入延迟（等主线程空闲）、事件处理耗时、渲染下一帧的耗时。优化的核心是让主线程尽快空出来：

• 拆分长任务：执行时间超过 50 毫秒的任务就是长任务，执行期间页面无法响应输入
• 及时让出主线程：用 setTimeout 分片，支持的浏览器中可以用 scheduler.yield()
• 减少不必要的渲染：避免一次交互触发大范围的组件更新和 DOM 操作
• 繁重计算移到 Web Worker（见 Web Worker）

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield()
  return new Promise((resolve) => setTimeout(resolve, 0))
}

async function processItems(items) {
  let start = performance.now()
  for (const item of items) {
    handle(item)
    // 连续执行超过 50ms 就让出一次主线程，让浏览器先响应输入、渲染页面
    if (performance.now() - start > 50) {
      await yieldToMain()
      start = performance.now()
    }
  }
}

优化 CLS#

• 图片、视频设置 width 和 height 属性，或者用 CSS 的 aspect-ratio，让浏览器提前预留空间
• 为广告、嵌入内容和动态加载的模块预留位置
• 不要在已有内容的上方插入内容（用户操作触发的除外）
• 字体使用合适的 font-display，尽量减少字体替换前后的尺寸变化
• 动画使用 transform，不要改 top、width 这类会影响布局的属性

面试官可能追问#

易错点#

• Core Web Vitals 目前只有 LCP、INP、CLS 三个，FCP、TTFB、TBT 是辅助指标
• Lighthouse 分数高不代表真实用户体验好，Google 评估用的是真实用户数据
• CLS 不是时间，而是一个没有单位的分数；用户操作后很短时间内发生的布局变化不计入