Core Web Vitals 详解与优化路线图：别再把性能当玄学

很多团队做性能优化的方式，像极了程序员版刮彩票：

图片大了，压一下
包体大了，拆一下
页面慢了，加缓存

听起来都对，但一套组合拳打完，数据面板还是不漂亮。

问题不在于大家不努力，而在于很多优化动作没有先回答一个更根本的问题：

你到底在优化什么样的“慢”？

性能从来不是单一指标。用户会同时感知三件事：

页面多久看起来“像是打开了”
页面会不会突然乱跳
我点了之后多久真的有反应

Core Web Vitals 正好对应这三种体验：

LCP：最大内容什么时候出现
CLS：布局是否稳定
INP：交互响应是否及时

这篇文章不打算再把每个缩写背一遍，而是想帮你建立一个更靠谱的框架：把性能问题拆成用户感知、资源加载、主线程占用、缓存策略、组件边界五个层面来治理。

1. 先把指标翻译成人话

1.1 LCP 不是“首页快不快”，而是“关键内容什么时候出现”

LCP 最大的误区是把它理解成“加载时间”。

更准确地说，它衡量的是：用户最关心的那块内容，什么时候终于出现在视口里。

在新闻站，它可能是文章标题或首图；在电商页，它常常是商品大图和价格区；在 SaaS 后台，它可能是表格主体。

所以优化 LCP，不是盲目压全站所有资源，而是优先保障“关键内容路径”。

1.2 CLS 不是样式问题，而是信任问题

页面突然跳一下，用户的第一反应不是“技术实现有点粗糙”，而是：

这网站不稳，我敢不敢继续点？

CLS 本质上在惩罚一种不负责任的界面承诺：你先给用户一个版面，随后又擅自把它改了。

广告位迟到、图片尺寸没占位、异步模块回填，都属于这个问题。

1.3 INP 不是事件处理慢，而是主线程被绑架

很多人把交互延迟归因于“接口慢”。

但真实情况常常是：点击已经发生，浏览器也准备响应了，只是主线程还在忙着做别的事。

比如：

一次点击触发了复杂状态更新
大型组件整树重渲染
第三方脚本占住了执行队列
JSON 解析和数据整形都在主线程硬扛

INP 的核心提醒是：交互卡顿，本质上是调度失败。

2. 一条更靠谱的性能诊断路径

如果你一上来就改代码，通常会在错误方向上越跑越快。建议按这个顺序做：

先看真实用户数据，再看实验室数据
先锁定页面模板，再看单一页面
先找控制面，再找具体实现细节

一个够用的诊断框架如下：

问题	优先检查	常见根因
LCP 差	首屏 HTML、关键 CSS、首图加载链路	服务端慢、阻塞资源多、图片策略差
CLS 差	首屏骨架、图片容器、广告/推荐位	没预留空间、异步回填、字体切换
INP 差	主线程长任务、事件回调、状态更新	组件过重、第三方脚本、同步计算

你会发现，性能问题大多不是“某一个函数写得烂”，而是架构默认值不对。

3. LCP 的治理路线：先把关键路径变短

LCP 的思路不是“让所有东西都快”，而是“让关键内容更早出现”。

3.1 先缩短服务端到首字节的距离

如果 HTML 本身出来得慢，后面的所有优化都像在堵车现场擦车窗。

先处理：

页面是否做了不必要的服务端串行请求
缓存是否区分了静态、弱动态、强个性化内容
首屏是否依赖重型鉴权和全量配置注入

3.2 再清理首屏阻塞资源

典型坏味道：

首屏前塞了多个阻塞脚本
一堆不是首屏必须的组件样式被同步拉入
大图没声明优先级，结果让埋点脚本抢了带宽

在 Nuxt 或现代前端项目里，可以优先做这三件事：

// 示例：优先加载首图，而不是等浏览器“自己猜”
useHead({
  link: [
    {
      rel: 'preload',
      as: 'image',
      href: '/images/hero.avif',
    },
  ],
})

3.3 别让首图又大又迟到

很多站点的 LCP 元素就是图片，但真正拖垮指标的不是“图片存在”，而是：

尺寸远大于实际展示尺寸
还在传 JPEG，而不是更合理的 WebP/AVIF
响应式尺寸缺失，移动端也在吃桌面图

一句话原则：让 LCP 元素成为带宽预算里的 VIP。

4. CLS 的治理路线：任何异步内容都必须先买座位

做 CLS 优化，最重要的不是技巧，而是一种界面伦理：

只要某个模块会来，就必须先给它留位置。

4.1 图片和媒体必须显式占位

<img
  src="/images/product.webp"
  width="960"
  height="640"
  alt="商品图"
/>

这看起来像老生常谈，但它依然是大量页面 CLS 的头号凶手。

4.2 骨架屏不是装饰，它是布局承诺

如果真实内容和骨架尺寸不一致，骨架屏就不是优化，而是一次双重欺骗。

好的骨架要做到：

与真实内容块尺寸一致
文本行高和图片区比例接近
数据回来时只做“内容替换”，不做布局重排

4.3 字体策略要服务稳定，不只是服务好看

自定义字体加载晚了，文本宽度变化也会造成布局抖动。处理思路：

使用合理的 fallback 字体
控制字体文件体积
只给关键字重加载自定义字重，不要一口气把全家桶都运来

5. INP 的治理路线：减少一次交互背后的系统反应过度

INP 差，通常意味着系统把一次用户动作，误处理成了一场全站广播。

5.1 先找长任务

浏览器最怕不是“事情多”，而是“有一件事情太久做不完”。

重点排查：

重型富文本解析
大 JSON 同步处理
点击后触发多层 store 更新
统计脚本、可视化脚本、客服脚本挤占主线程

5.2 缩小响应边界

交互优化很大程度上是组件设计问题。

如果一个筛选按钮被点击后，会导致整个页面树重渲染，那不是 React、Vue 或浏览器的错，是边界切错了。

更好的做法是：

把热交互区域做局部状态隔离
避免把短周期状态抬到全局
重计算任务异步化，或者延后到空闲时段

function expensiveNormalize(list: Array<Record<string, unknown>>) {
  return list.map((item) => ({
    ...item,
    keywords: String(item.title || '')
      .toLowerCase()
      .split(' '),
  }))
}

requestIdleCallback(() => {
  cachedResult.value = expensiveNormalize(rawList.value)
})