跳到主要内容

Web Vitals

面试速答（30 秒版 TL;DR）​

  • Web Vitals 是 Google 推动的一组 Web 用户体验指标；其中当前稳定的 Core Web Vitals 是：LCP、INP、CLS。
  • 截至 2026-03，稳定核心指标仍是：
    • LCP：加载体验
    • INP：交互响应
    • CLS：视觉稳定
  • 需要特别记住一个时间点：2024-03-12，INP 正式替代 FID 成为 Core Web Vital。
  • 一句话记忆：Web Vitals 不是只看“快不快”，而是同时看“内容多久出来、点了多久有反馈、页面会不会乱跳”。

心智模型：三个指标分别盯三种用户痛点​

用户对一个页面最直观的抱怨，通常就三类：

  1. 怎么还没出来，对应加载体验
  2. 我都点了怎么没反应，对应交互体验
  3. 页面怎么老在跳，对应视觉稳定性

Core Web Vitals 正好就围绕这三件事定义：

  • LCP（Largest Contentful Paint）：核心内容多久出现
  • INP（Interaction to Next Paint）：用户交互后多久看到下一次绘制反馈
  • CLS（Cumulative Layout Shift）：页面有没有发生意外位移

一张图先记住框架​

先把三个指标和对应用户痛点绑死。

当前稳定 Core Web Vitals 是哪些​

根据 web.dev 当前稳定说明：

  • LCP 小于等于 2.5s 算好
  • INP 小于等于 200ms 算好
  • CLS 小于等于 0.1 算好

并且更稳妥的表达方式是：

Core Web Vitals 的评估不是看单次最好成绩，而是看真实用户访问中第 75 百分位是否达到目标。

这句话在面试里很重要，因为它说明你知道：

  • 指标强调真实用户体验
  • 不是只看实验室单次跑分
  • 也不是只看桌面端

指标总表​

指标关注点好阈值典型坏因最直接优化抓手
LCP首屏关键内容出现速度<= 2.5s慢服务器、阻塞资源、首屏图太慢、客户端渲染过重降低 TTFB、优化首屏资源、提升首屏图加载优先级
INP用户交互到页面反馈的整体时延<= 200ms长任务、主线程过忙、布局抖动、复杂 JS切长任务、减主线程压力、减少同步布局与重渲染
CLS页面加载和交互中的意外位移<= 0.1图片没尺寸、广告/插槽占位不足、异步插入内容、字体切换预留空间、稳定布局、减少后插内容挤压

1. LCP：用户什么时候看到“主要内容”​

LCP 关注的是：

  • 当前视口中最大的内容元素，什么时候真正渲染出来

在实际项目里，LCP 候选往往是：

  • Hero 大图
  • 首屏大标题块
  • 头图视频封面
  • 大块文本容器

为什么 LCP 差​

高频原因通常是：

  • 服务端响应慢，TTFB 高
  • 关键 CSS / JS 阻塞
  • 首屏图过大、格式差、优先级不够
  • 页面严重依赖客户端渲染，关键内容出得晚

优化抓手​

  • 减少服务端首字节时间
  • 缩短关键资源链
  • 给首屏核心图片合理尺寸、压缩和高优先级加载
  • 非关键 JS 延后
  • 对内容页、商品页这类首屏可预知页面优先做 SSR/SSG 或静态化

面试里可以把它总结成：

LCP 的本质不是“整页什么时候彻底加载完”，而是“用户最关心的那块内容什么时候能看见”。

2. INP：用户点了之后，页面多久真的动起来​

INP 是最容易被问的新指标。

要点先记住：

  • 它衡量的是交互到下一次绘制的整体延迟
  • 比旧指标 FID 更完整
  • 已在 2024-03-12 正式替代 FID

为什么 FID 不够用了​

FID 只看：

  • 用户第一次输入后，事件处理开始前等了多久

它没完整覆盖：

  • 事件处理本身有多慢
  • 处理完后渲染更新有多慢

所以 INP 更贴近真实体验，因为它关心的是：

  • 用户交互
  • 事件开始处理
  • JS 执行
  • 布局 / 绘制
  • 最终看到反馈

INP 差的典型原因​

  • 长任务太多，主线程被占满
  • 同步 JS 过重
  • 大量组件在一次交互里连锁更新
  • 复杂 DOM 和样式导致交互后重新布局成本高
  • 读写布局交替，出现 layout thrashing

优化抓手​

  • 把长任务切碎，避免主线程长期被单个任务霸占
  • 减少一次交互触发的同步计算
  • 把非关键工作延后
  • 减小 DOM 规模和样式计算成本
  • 避免交互后频繁强制同步布局

面试时一句话解释 INP：

INP 关心的是“用户操作后多久看到页面真正反馈”，所以它覆盖的不只是输入排队，还包含 JS 执行和后续渲染成本。

3. CLS：页面别乱跳​

CLS 衡量的是：

  • 页面在非预期情况下发生了多少布局位移

用户最反感的场景就是：

  • 我正准备点按钮，按钮突然被广告或图片顶下去了
  • 字体切换后整块文案位置变了
  • 异步插入模块把正文挤开

CLS 的常见来源​

  • 图片、视频、广告位没有预留尺寸
  • 动态插入内容把已有内容往下顶
  • 字体加载后字重 / 字宽变化明显
  • 在已有内容上方插入横幅、提示条

优化抓手​

  • 给图片和媒体元素显式宽高或占位比
  • 广告、推荐位、骨架屏提前占位
  • 谨慎在视口顶部动态插入内容
  • 控制 Web Font 的加载和回退策略

一个能加分的表达是：

CLS 不是“动效分数”，而是“非预期位移分数”。有意设计的动画不一定有问题，关键是别让用户操作目标突然跑掉。

Web Vitals 怎么测：先分清实验室数据和真实用户数据​

这是另一个高频追问点。

真实用户数据（Field）​

适合回答：

  • 线上用户实际体验到底怎样
  • 发布后有没有回退
  • 不同国家、设备、网络是否差异明显

常见来源：

  • CrUX（Chrome User Experience Report）
  • PageSpeed Insights
  • Search Console
  • 你自己的 RUM 采集

实验室数据（Lab）​

适合回答：

  • 本地调试和性能回归
  • 定位阻塞资源、长任务、渲染问题

常见工具：

  • Lighthouse
  • Chrome DevTools Performance

一个必须说准的点​

web.dev 明确提醒：

  • Lighthouse 这种没有真实用户输入的实验环境，不能直接测 INP
  • 在实验室里通常会用 TBT（Total Blocking Time） 作为 INP 的代理指标

所以如果面试官问：

为什么 Lighthouse 很好看，线上体验还是差？

你可以回答：

因为 Lighthouse 更偏实验室环境，适合定位问题；而 Core Web Vitals 真正评估更看真实用户第 75 百分位。尤其 INP 强依赖真实交互路径，实验室跑分不能完全替代线上 RUM。

一个很实用的采集示例​

如果项目要自己接入监控，通常不会手写底层 API，而会直接用 web-vitals 库。

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

function reportMetric(name: string, value: number) {
  navigator.sendBeacon(
    '/rum',
    JSON.stringify({
      name,
      value,
      url: location.href,
      ts: Date.now(),
    }),
  )
}

onLCP((metric) => reportMetric('LCP', metric.value))
onINP((metric) => reportMetric('INP', metric.value))
onCLS((metric) => reportMetric('CLS', metric.value))

这个示例体现两个思路：

  • 线上监控应该基于真实访问采集
  • 指标上报要带页面地址、时间和设备上下文，方便回溯

一条很适合面试表达的优化流程​

这个流程的价值在于：

  • 先确认是不是线上真实问题
  • 再做实验室定位
  • 最后回到线上验证

避免了“只盯 Lighthouse 分数优化”的伪努力。

常见业务场景怎么对应指标​

页面类型最该先盯的指标原因
内容页、官网首页、商品详情页LCP用户先看首屏内容是否尽快出现
控制台、表格页、富交互后台INP用户大量点击、筛选、输入，响应迟钝最敏感
信息流、广告位多、异步模块多的页面CLS版位和动态模块容易挤压页面

典型题 & 标准答法​

Q1：Core Web Vitals 现在包含哪些指标？​

答：截至 2026 年 3 月，稳定的 Core Web Vitals 是 LCP、INP 和 CLS，分别衡量加载性能、交互响应和视觉稳定性。需要特别注意的是，INP 已在 2024 年 3 月 12 日正式替代 FID。

Q2：为什么 INP 比 FID 更合理？​

答：FID 主要看第一次输入从发生到事件开始处理前的等待时间，没有完整覆盖事件处理和渲染反馈成本；INP 衡量的是交互到下一次绘制的整体时延，更贴近用户真实感知，因此更适合作为响应性指标。

Q3：为什么不能只看 Lighthouse？​

答：因为 Lighthouse 属于实验室数据，适合定位性能问题，但不等于线上真实用户体验。Core Web Vitals 更强调真实访问下第 75 百分位的表现。尤其 INP 强依赖真实用户交互路径，实验室通常只能用 TBT 近似参考。

Q4：LCP、INP、CLS 分别该怎么优化？​

答：LCP 重点是缩短关键资源链和首屏内容出现时间；INP 重点是减主线程压力、切长任务、减少交互后的重计算与重布局；CLS 重点是提前占位、稳定布局、避免异步内容把已有元素顶走。

常见追问​

  • 为什么 PageSpeed Insights 和自己埋点的数据可能不完全一样？
  • 为什么桌面端过了，移动端还是不过？
  • INP 差到底该先查 JS、样式还是 DOM？
  • 为什么有些页面 LCP 正常，但用户还是觉得“点不动”？

易错点​

  • 不要再把 FID 当当前核心指标讲。从 2024-03-12 起，核心响应指标已经是 INP。
  • 不要把 Web Vitals 说成纯“SEO 分数”。它首先是用户体验指标，SEO 只是受它影响的结果之一。
  • 不要把 CLS 理解成“页面有动画就扣分”。关键是非预期布局位移。
  • 不要只盯实验室跑分。线上真实用户数据才决定 Core Web Vitals 是否真正达标。

速记要点​

  • LCP：内容多久出现。
  • INP：点了多久有反馈。
  • CLS：页面会不会乱跳。
  • 看第 75 百分位，不看单次最好成绩。
  • 2024-03-12：INP 替代 FID。