Core Web Vitals 与前端性能优化

做过前端的人多少都听过 Core Web Vitals(核心 Web 指标,简称 CWV),但很多团队对它的理解停留在"Google 给的 SEO 评分"。这种认知是偏的。CWV 真正的价值在于:它把"用户觉得这个站快不快"这件主观的事,变成了可量化、可监控、可优化的三个数。

这篇文章我把三大指标讲透,顺带把实战中真正有效的优化手段列出来。

一、为什么 Core Web Vitals 值得你认真对待

两个理由,缺一不可。

第一,它是用户体验的量化。过去我们说"这个页面卡",到底多卡?首屏 1.8 秒和 2.6 秒,用户感受差别多大?没人说得清。CWV 给了三把尺子:加载、响应、视觉稳定。一把测"多久能看见主要内容",一把测"点了之后多久有反应",一把测"看得过程中内容会不会乱跳"。这三件事恰好覆盖了用户对"快"的全部感知。

第二,它是 Google 的排名信号。2021 年起 CWV 正式纳入页面体验信号(Page Experience Signal),影响搜索排名。2024 年 3 月,INP 正式替代 FID 成为新的响应性指标——这件事很多团队还没反应过来,排名已经在悄悄变化了。

所以 CWV 不是"做了更好"的可选项,而是"不做会丢流量"的硬指标。

二、三大指标:各自测什么,目标是多少

1. LCP(Largest Contentful Paint,最大内容绘制)

测的是加载性能:从页面开始加载到视口内最大的元素(通常是 Hero 图、大标题、视频封面)完成渲染的时间。

• 目标:< 2.5s(达到 75 分位即算"良好")
• 及格线:2.5s – 4.0s 之间为"需改进"
• 差:> 4.0s

为什么选"最大元素"而不是 onload?因为 onload 衡量的是资源下载完毕,不代表用户"看见"了主内容。一张占满首屏的 Hero 图,才是用户判定"页面出来了"的真正信号。

2. INP(Interaction to Next Paint,交互到下一帧)

测的是响应性:用户在整个页面生命周期中所有交互(点击、键盘输入、点按)的延迟,取最差的那次(严格说是 P98)。

• 目标:< 200ms
• 及格线:200ms – 500ms
• 差:> 500ms

注意:INP 测的是"所有交互",不是只测首次输入。这正是它 2024 年 3 月替代 FID 的原因——FID 只测第一次点击的"首次输入延迟",对 SPA 这种"首次挺快,后续越用越卡"的场景完全失明。INP 把整段使用体验纳入考核,门槛一下就高了一截。

200ms 这个阈值也值得记住:从用户点击到屏幕上像素发生变化,超过 200ms 人就能明显感觉到"卡了一下"。

3. CLS(Cumulative Layout Shift,累积布局偏移)

测的是视觉稳定性:页面整个生命周期内,元素意外移动的累积分数。

• 目标:< 0.1
• 及格线:0.1 – 0.25
• 差:> 0.25

典型场景:你正要点"购买"按钮,上方突然插入了一张广告图,按钮被挤下去了,你点到了广告。这种"点错"的体验就是 CLS 在惩罚的。

三、怎么测:实验室数据 vs 真实用户数据

性能测量有两条路,必须一起用,只看一条会被骗。

实验室数据(Lab Data):在受控环境(固定网络、固定设备)里跑 Lighthouse 模拟。优点是可复现、适合 CI 卡阈值、本地调试方便;缺点是它跑的是"一个理想用户",不代表真实用户。

现场数据(Field Data):来自真实用户的浏览器上报,数据汇聚在 Chrome UX Report(CrUX)里。这才是 Google 算排名时用的数据。也就是说,你的 Lighthouse 跑 100 分,不代表 CrUX 数据好,排名信号看的是后者。

落地工具:

• Lighthouse:Chrome DevTools 自带,跑一次给你 Lab Data + 一堆建议。CI 里可以用 Lighthouse CI 自动卡阈值。
• web-vitals 库:Google 官方 JS 库,在你的代码里 import { onINP, onLCP, onCLS } from 'web-vitals',把真实用户数据上报到自己的监控(Grafana / Sentry / Datadog)。这是采集 Field Data 的标准方式。
• PageSpeed Insights(PSI):输入 URL,同时返回 Lighthouse 跑的 Lab Data 和 CrUX 的 Field Data。最直观,适合快速体检。
• Search Console 的"核心 Web 指标"报告:直接告诉你哪些 URL 在 CrUX 里是不及格的,按问题类型分组。免费且权威,SEO 同事最爱。

四、LCP 优化:让主内容更快被看见

LCP 元素 90% 的情况下是图片,其次是文字块、背景图、视频封面。优化围绕四条线:

1. 图片优先加载。LCP 图必须 fetchpriority="high",必要时给 <link rel="preload" as="image">。React/Next.js 项目里别让 LCP 图走 loading="lazy"——这是新手最容易踩的坑,把最重要的图设成懒加载,LCP 直接崩。

2. 选对图片格式和尺寸。WebP/AVIF 比 PNG/JPEG 小 30%–50%,AVIF 更狠。但要注意 AVIF 在老浏览器上 fallback。Next.js 的 next/image 会自动按设备 DPR 生成响应式 srcset,该用就用,别手写 <img>。

3. 服务器响应(TTFB)。LCP 的下限是 TTFB,服务端慢一切白搭。上 CDN、做边缘渲染(Next.js 的 Edge Runtime)、合理缓存 HTML、避免首屏接口串行调用。

4. 消除渲染阻塞资源。同步的 CSS、首屏不需要的 JS,该 defer 的 defer、该 async 的 async。但别动关键的 CSS——首屏 CSS 抽出来 inline 到 HTML,能显著缩短 LCP。

5. 字体。系统字体最快;用 Web Font 时务必 font-display: swap,避免 FOIT(字体加载期间文字不可见)拖累 LCP。

五、INP 优化:让交互"跟手"

INP 高,99% 是主线程被长任务(Long Task,>50ms)占满了,用户点击的事件处理器排不上队。优化思路:

1. 拆长任务。一个跑 200ms 的同步函数,把它切成小块,用 setTimeout 或更现代的 scheduler.yield() 让出主线程:

// 让出主线程,让浏览器处理待办的输入/绘制
await scheduler.yield();

scheduler.yield() 是 2024 年后的新 API,比 setTimeout(0) 更可靠,优先级更好,目前主流浏览器支持已经不错。

2. 减少主线程上的 JS 执行。重计算挪到 Web Worker;React 大列表用虚拟滚动(react-virtual、@tanstack/react-virtual);避免 JSON.parse 巨大字符串在主线程同步跑。

3. 防抖节流。scroll / resize / input 这些高频事件必须节流,且处理器本身要轻。别在 scroll 里跑 getBoundingClientRect(它强制同步布局,即 layout thrashing)。

4. 用 React 的并发特性。useTransition 把"不紧急的状态更新"标记为低优先级,让 React 优先响应用户输入:

const [isPending, startTransition] = useTransition();

function handleSearch(value) {
  startTransition(() => {
    setResults(filterHugeList(value)); // 这个更新不会阻塞用户输入
  });
}

这是 React 18+ 给我们的硬核武器,在搜索、筛选、Tab 切换等场景下对 INP 立竿见影。

六、CLS 优化:别让页面"跳"

CLS 高,基本是布局尺寸没提前定好。三条铁律:

1. 图片/视频/iframe 必须设尺寸。width/height 或 CSS aspect-ratio。Next.js next/image 要求你给 width/height 或 fill + 容器尺寸,就是在防这个——尺寸定了,图片加载完只是内容填充,不会推开兄弟元素。

2. 广告、嵌入、动态插入的内容预留空间。广告位先占好高度,别让脚本回来把它撑开;Web Component 嵌入同理。第三方 widget 是 CLS 的重灾区。

3. 字体加载策略。字体切换导致文字宽度变化(font-display: swap 会先显示系统字体,加载完后切换,产生布局偏移)。缓解手段:size-adjust、font-display: optional(等不及就直接用系统字体),或用 font-matches 之类技巧预匹配度量。

七、实验室数据 ≠ 现场数据,记住这点

最容易翻车的认知:Lighthouse 跑满分,Google Search Console 还是报警。

原因很简单:Lighthouse 在一台机器上、一个固定网络下、跑一次,得出来的是"理想情况"。而 CrUX 收集的是真实用户——有人用着 5 年前的中端 Android 机、在 3G 网络下打开你的页面,他的 LCP 可能是你 Lighthouse 数值的 3 倍。

所以现场数据(CrUX)才是排名信号,Lab 数据是排查工具。正确的姿势是:

1. 先看 Search Console / PSI 的 Field Data,定位哪些 URL、哪个指标不及格。
2. 在那些 URL 上跑 Lighthouse + Performance 录制,定位根因(哪张图太慢、哪个任务太长)。
3. 改完之后,用 web-vitals 库上报真实数据持续监控,而不是只看 Lighthouse。

CI 里卡 Lighthouse 阈值是好习惯,但别把它当成"性能 OK"的证明。

小结

• 三大指标各司其职:LCP 看加载、INP 看响应、CLS 看稳定。分别瞄准 2.5s / 200ms / 0.1。记住这三个数,优化就有方向。
• INP 是 2024 年 3 月起的新硬指标,替代了 FID。它考核全部交互,不是首次。SPA 团队尤其要重新评估。
• Lighthouse 是体检,CrUX 才是成绩单。Google 排名看的是 CrUX 的真实用户数据,Lab 数据快不代表真实用户快。
• LCP 抓图片、CLS 抓尺寸、INP 抓主线程,这是最高 ROI 的三条线。
• React 18+ 的 useTransition、scheduler.yield()、next/image 这些工具用起来,别用 2019 年的方式写 2026 年的性能。

一句话收尾:性能优化不是把指标刷到绿色,是让真实用户少等一秒。 CrUX 数据好看了,SEO 自然就来了,但更重要的是——那个在地铁上用 4G 打开你站点的用户,今天少骂了一句。