前端性能实战：基于 Core Web Vitals 的页面加载优化与排查指南

前端性能优化这件事，最怕的不是“不会做”，而是“做了很多，但不知道有没有用”。我见过不少项目把图片压缩、代码分包、CDN、懒加载全都上了一遍，结果线上用户还是觉得慢。原因通常不是没有优化，而是没有围绕真正影响体验的指标去优化。

Core Web Vitals 就是那个“抓主矛盾”的工具。它不是泛泛地说“页面要快”，而是直接告诉你：首屏主要内容何时出现、交互何时变得流畅、页面是否乱跳。这篇文章我会按“排查指南”的方式来写：先讲问题表现，再讲原理，再带你走一遍定位路径，最后给出可运行代码和一套止血方案。

背景与问题

很多页面性能问题，并不是简单的“资源大”这么单一。更常见的场景是这样的：

页面首屏白屏时间长，用户以为没打开
首屏文字出来了，但大图很久才显示
点击按钮没反应，过一会儿才一起执行
页面刚能看时，广告、图片、异步模块又把布局顶乱了
本地测试很快，线上移动端和弱网环境却很差

如果你也遇到这些现象，通常可以映射到 Core Web Vitals 的三个核心指标：

LCP（Largest Contentful Paint）：最大内容绘制时间，衡量“主要内容何时出现”
INP（Interaction to Next Paint）：交互到下一次绘制的时间，衡量“页面操作是否跟手”
CLS（Cumulative Layout Shift）：累计布局偏移，衡量“页面是否乱跳”

一个很现实的问题是：
用户抱怨“卡”和“慢”，往往不是单一指标差，而是加载链路、主线程阻塞、资源优先级和布局策略一起出了问题。

先看一眼：性能排查总流程

下面这张图可以作为整篇文章的导航。实际排查时，我基本也是按这个路径走。

flowchart TD
  A[用户反馈 页面慢/卡/乱跳] --> B[确定问题指标 LCP/INP/CLS]
  B --> C[采集数据 Lab + RUM]
  C --> D{主要问题是什么}
  D -->|LCP差| E[查首屏资源/TTFB/渲染阻塞/图片]
  D -->|INP差| F[查长任务/事件回调/第三方脚本]
  D -->|CLS差| G[查无尺寸资源/动态插入/字体切换]
  E --> H[优化并回归验证]
  F --> H
  G --> H
  H --> I[灰度上线并监控]

核心原理

Core Web Vitals 到底在衡量什么

1. LCP：用户什么时候“看到重点内容”

LCP 常见候选元素包括：

首屏大图
banner
首屏大块文本
hero 区域的背景图（某些情况下）

影响 LCP 的关键因素通常有 4 类：

TTFB 太高：服务端响应慢，浏览器拿不到 HTML
资源发现太晚：关键图片、关键 CSS 没有尽早请求
渲染阻塞：CSS、同步 JS 阻塞首屏渲染
资源本身太大：大图未压缩、格式不合适、未裁剪

可以简单把它理解成：

LCP = 服务端响应 + 浏览器解析 + 关键资源加载 + 元素绘制

2. INP：页面能不能及时响应用户操作

INP 关注的是一次交互从开始到页面下一次可见更新之间的延迟。
典型问题包括：

点击按钮触发大量同步计算
输入框联想、过滤、表格渲染都在主线程一次性完成
第三方埋点、监控、广告脚本占用主线程
React/Vue 组件更新范围过大

很多人以前只盯着 FID，但现在实际更该关注 INP，因为它更接近真实交互体验。

3. CLS：为什么页面会“乱跳”

CLS 典型来源：

图片、视频、iframe 没设宽高
广告位、弹窗位异步插入
字体加载后替换导致文字重排
在已有内容上方动态插入公告条、营销条

这个指标很“气人”，因为它常常不是页面慢，而是让用户点错、看错、滚错。

Core Web Vitals 与页面加载链路关系

sequenceDiagram
  participant U as 用户
  participant B as 浏览器
  participant S as 服务端
  participant C as CSS/JS
  participant I as 首屏图片

  U->>B: 访问页面
  B->>S: 请求 HTML
  S-->>B: 返回 HTML
  B->>C: 请求关键 CSS/JS
  B->>I: 请求首屏图片
  C-->>B: CSS/JS 返回
  I-->>B: 图片返回
  B-->>U: 绘制首屏内容(LCP)
  U->>B: 点击/输入
  B-->>U: 响应并更新(INP)
  Note over B,U: 若布局被异步内容顶开，则产生 CLS

现象复现：一个“看起来正常，其实指标很差”的页面

先做一个最小复现。这个例子故意制造了几个问题：

阻塞式脚本
未声明尺寸的图片
点击按钮时执行长任务
动态插入顶部提示条导致布局偏移

你可以直接保存成 index.html 运行。

<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Core Web Vitals 问题复现</title>
  <style>
    body {
      margin: 0;
      font-family: Arial, sans-serif;
    }
    .hero {
      padding: 24px;
    }
    .banner {
      display: block;
      width: 100%;
      max-width: 960px;
      margin: 0 auto;
    }
    .content {
      max-width: 960px;
      margin: 24px auto;
      padding: 0 16px;
    }
    .btn {
      padding: 10px 16px;
      font-size: 16px;
      cursor: pointer;
    }
    .list {
      margin-top: 16px;
    }
    .item {
      padding: 8px 0;
      border-bottom: 1px solid #eee;
    }
    .notice {
      background: #ffefc1;
      padding: 12px 16px;
      font-size: 14px;
    }
  </style>

  <script>
    // 模拟阻塞主线程
    const start = performance.now();
    while (performance.now() - start < 1200) {}
  </script>
</head>
<body>
  <div class="hero">
    <h1>欢迎来到性能问题复现场景</h1>
    <p>这个页面故意制造 LCP / INP / CLS 问题。</p>
    <!-- 故意不写 width/height -->
    <img
      class="banner"
      src="https://images.unsplash.com/photo-1500530855697-b586d89ba3ee?q=80&w=1600&auto=format&fit=crop"
      alt="banner"
    />
  </div>

  <div class="content">
    <button class="btn" id="heavyBtn">点击执行重任务</button>
    <div class="list" id="list"></div>
  </div>

  <script>
    // 动态插入顶部提示，制造 CLS
    setTimeout(() => {
      const notice = document.createElement('div');
      notice.className = 'notice';
      notice.textContent = '这是一个异步插入的顶部通知，会导致页面发生位移。';
      document.body.insertBefore(notice, document.body.firstChild);
    }, 1500);

    // 点击时执行长任务，制造 INP 问题
    document.getElementById('heavyBtn').addEventListener('click', () => {
      const list = document.getElementById('list');
      list.innerHTML = '';

      const start = performance.now();
      while (performance.now() - start < 800) {}

      const fragment = document.createDocumentFragment();
      for (let i = 0; i < 500; i++) {
        const div = document.createElement('div');
        div.className = 'item';
        div.textContent = `列表项 ${i + 1}`;
        fragment.appendChild(div);
      }
      list.appendChild(fragment);
    });
  </script>
</body>
</html>

这个页面在 Lighthouse 里通常会出现：

LCP 偏差：同步脚本阻塞 + 首屏图片大
INP 偏差：点击事件内长任务
CLS 偏差：顶部 notice 动态插入

定位路径：不要一上来就改代码，先确认“慢在哪里”

排查性能问题，我建议分三层看：

第一层：用户真实数据

优先看线上真实用户监控（RUM）：

不同机型、网络、地域是否差异明显
问题出现在首屏、交互还是布局稳定性
是否某个页面、某个版本、某个活动期间突然变差

如果没有完整 RUM，也至少接入 web-vitals 做基础采样。

第二层：实验室数据

用这些工具交叉验证：

Chrome DevTools Performance
Lighthouse
PageSpeed Insights
WebPageTest

要注意：

Lighthouse 偏“受控环境”
PageSpeed Insights 会结合真实用户数据
DevTools 更适合你本地逐帧定位

第三层：资源与主线程细节

重点看三类信息：

Network
- 首屏资源谁最慢
- 有没有串行请求
- 是否关键图片请求太晚
- 是否有大 JS 包占首屏带宽
Performance
- 有没有 Long Task
- 哪段 JS 占主线程最久
- 布局、样式计算、重排是否频繁
Elements / Rendering
- LCP 元素到底是谁
- 布局偏移由哪个节点引起
- 字体、广告、异步组件是否影响稳定性

实战代码：接入 web-vitals 采集真实指标

先安装依赖：

npm install web-vitals

然后在前端入口文件里上报指标：

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

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    rating: metric.rating,
    url: location.href,
    userAgent: navigator.userAgent,
    ts: Date.now()
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/perf', body);
  } else {
    fetch('/api/perf', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body,
      keepalive: true
    });
  }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

如果你想在本地控制台直接看结果，也可以这样写：

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

onLCP((metric) => {
  console.log('LCP', metric);
});

onINP((metric) => {
  console.log('INP', metric);
});

onCLS((metric) => {
  console.log('CLS', metric);
});

一个简单的 Node.js 接收端示例：

import express from 'express';

const app = express();
app.use(express.json());

app.post('/api/perf', (req, res) => {
  console.log('perf metric:', req.body);
  res.status(204).end();
});

app.listen(3000, () => {
  console.log('server running at http://localhost:3000');
});

实战优化一：LCP 差，优先查首屏资源链路

典型症状

首屏大图迟迟不出现
Lighthouse 提示 LCP 资源发现过晚
首屏图片在瀑布图里排得很靠后

止血方案

1）给首屏图片更高优先级

<link
  rel="preload"
  as="image"
  href="/images/hero.avif"
  imagesrcset="/images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
  imagesizes="100vw"
/>

<img
  src="/images/hero.avif"
  srcset="/images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
  sizes="100vw"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="首页主视觉"
/>

2）避免首屏图片被懒加载

这个坑我踩过一次：团队统一给所有图片都加了 loading="lazy"，结果首页 hero 图直接被延迟加载，LCP 反而更差。

正确做法：

<!-- 首屏关键图不要 lazy -->
<img
  src="/images/hero.avif"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="hero"
/>

<!-- 非首屏图片才懒加载 -->
<img
  src="/images/card-1.webp"
  loading="lazy"
  width="400"
  height="300"
  alt="card"
/>

3）减少渲染阻塞

把非关键 JS 延后，把关键 CSS 内联或拆小。

<!-- 关键 CSS 可考虑内联 -->
<style>
  .hero-title { font-size: 40px; margin: 0; }
</style>

<!-- 非关键脚本 defer -->
<script defer src="/js/app.js"></script>
<script defer src="/js/analytics.js"></script>

4）控制服务端响应时间

如果 TTFB 高，前端再怎么抠细节也有限。
常见方向：

SSR 缓存
CDN 边缘缓存
API 聚合减少首屏串行请求
避免服务端模板阻塞

实战优化二：INP 差，核心是减少主线程长任务

典型症状

点击按钮后“卡住”
输入时掉帧
切换筛选条件明显延迟

先看一个糟糕写法

button.addEventListener('click', () => {
  const result = bigArray
    .filter(item => heavyCheck(item))
    .map(item => expensiveFormat(item));

  renderBigList(result);
});

问题在于：
过滤、转换、渲染全部挤在一次交互里同步执行。

优化思路

1）把重计算移出主线程

const worker = new Worker('/worker.js', { type: 'module' });

button.addEventListener('click', () => {
  worker.postMessage({ list: bigArray });
});

worker.onmessage = (e) => {
  renderBigList(e.data);
};

worker.js：

self.onmessage = (e) => {
  const { list } = e.data;

  const result = list
    .filter(item => item.visible)
    .map(item => ({
      id: item.id,
      text: `${item.name} - ${item.score}`
    }));

  self.postMessage(result);
};

2）把大任务切片

function chunkProcess(items, handler, chunkSize = 50) {
  let index = 0;

  function run() {
    const end = Math.min(index + chunkSize, items.length);
    for (; index < end; index++) {
      handler(items[index], index);
    }

    if (index < items.length) {
      setTimeout(run, 0);
    }
  }

  run();
}

使用：

button.addEventListener('click', () => {
  const fragment = document.createDocumentFragment();

  chunkProcess(bigArray, (item) => {
    const div = document.createElement('div');
    div.textContent = item.name;
    fragment.appendChild(div);
  });

  requestAnimationFrame(() => {
    list.appendChild(fragment);
  });
});

3）避免无差别整树更新

如果你在 React/Vue 里遇到 INP 差，优先检查：

一个输入是否触发整页 rerender
列表是否缺少虚拟滚动
memo / computed / 缓存是否缺失
状态提升是否过头

实战优化三：CLS 差，先把“空间预留”做好

错误写法

<img src="/images/product.webp" alt="商品图" />

浏览器在图片加载前不知道它占多大空间，等图片来了就会把内容顶开。

正确写法

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

视频、广告、异步容器也一样

<div class="ad-slot"></div>

.ad-slot {
  width: 100%;
  min-height: 250px;
  background: #f5f5f5;
}

顶部通知不要硬插入文档流

错误方式是异步插入到页面最顶端。
更稳妥的做法：

<div id="notice-anchor" class="notice-anchor"></div>

.notice-anchor {
  min-height: 48px;
}
.notice {
  background: #ffefc1;
  padding: 12px 16px;
}

setTimeout(() => {
  const notice = document.createElement('div');
  notice.className = 'notice';
  notice.textContent = '系统通知：活动已开始';
  document.getElementById('notice-anchor').appendChild(notice);
}, 1500);

一张图看懂三类问题与对应抓手

classDiagram
  class LCP {
    +目标: 更快看到主要内容
    +关注: TTFB
    +关注: 关键资源发现
    +关注: 图片与CSS
  }

  class INP {
    +目标: 更快响应交互
    +关注: Long Task
    +关注: 事件处理
    +关注: 大量渲染
  }

  class CLS {
    +目标: 页面稳定不乱跳
    +关注: 预留空间
    +关注: 动态插入
    +关注: 字体切换
  }

常见坑与排查

1. Lighthouse 分数还行，但用户仍然觉得慢

这通常说明：

你只看了实验室数据，没看真实用户数据
高端电脑模拟结果不错，但低端安卓机很差
某些第三方脚本只在线上生效

建议：
把指标按设备等级、网络类型、页面类型拆开看，不要只看全站平均值。

2. 首屏图明明压缩了，LCP 还是差

常见原因不是图片本身太大，而是：

图片在 HTML 里出现太晚
被 JS 动态插入
被 loading="lazy" 延迟
CSS background-image 发现时机更晚
关键 CSS 阻塞，图片到了也画不出来

排查方法：

看 Network 瀑布图中图片何时开始请求
看 Performance 中 LCP 元素是谁
看是否有阻塞 CSS/JS 压住绘制

3. 我已经做了代码分包，为什么 INP 还是差

因为代码分包主要改善的是“加载体积”，而 INP 更常和“交互时主线程忙不忙”有关。

例如：

点击后做复杂排序
一次渲染几千条 DOM
频繁触发布局测量
组件联动更新过多

排查关键点：

Performance 面板里找 Long Task
找交互事件后的脚本执行峰值
检查是否有同步 getBoundingClientRect()、offsetHeight 读写穿插

4. CLS 明明不高，但用户还是抱怨“页面乱”

这类情况有两个可能：

问题发生频率低，但恰好发生在关键交互区域
偏移值不大，但位置很敏感，比如“提交按钮”“购买按钮”附近

所以 CLS 不只是看总分，也要看：

偏移发生在哪
是不是关键区域
是否在用户准备点击时发生

5. 第三方脚本拖慢页面，但业务又不能下掉

这是线上很常见的现实问题。
比如广告、埋点、A/B 测试、客服系统，你很难说删就删。

可行做法：

延后到首屏稳定后加载
使用 defer / async
放进 Web Worker 的就尽量放
对第三方脚本做预算和 SLA
分环境、分页面按需启用

安全/性能最佳实践

性能和安全其实并不矛盾，很多好习惯是同时受益的。

1）静态资源走 HTTPS 与强缓存

Cache-Control: public, max-age=31536000, immutable

配合文件名 hash：

app.a8f3c1.js
hero.92cd11.avif

这样既能提升命中率，也能避免缓存污染问题。

2）合理使用 `preconnect`

对确实需要的第三方源提前建连：

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

但不要滥加，预连接太多也会浪费资源。

3）控制第三方脚本权限与时机

不要把不可信脚本直接塞进关键渲染路径
使用 CSP 限制脚本来源
对 iframe 第三方内容使用 sandbox
能异步就异步，能延后就延后

4）避免内联大脚本和大 JSON

有些 SSR 页面喜欢在 HTML 里塞一大段首屏数据，看起来少一次请求，但会导致：

HTML 体积变大
TTFB 变高
解析时间变长

更稳妥的做法是：

只内联首屏必需的少量数据
非关键数据延后请求
大 JSON 做裁剪

5）建立性能预算

这个方法很朴素，但特别有效。
你不设上限，包体和脚本一定会慢慢长回来。

例如：

首屏 JS 小于 170KB gzip
LCP P75 小于 2.5s
INP P75 小于 200ms
CLS P75 小于 0.1
单个第三方脚本执行时间小于 50ms

6）把性能检测接入 CI

比如在 PR 阶段做基础校验：

Lighthouse CI
Bundle size 对比
关键页面快照回归

这样性能问题不会总等到线上才发现。

一套我常用的排查顺序

如果你现在手上就有一个“首屏慢”的页面，我建议直接按下面顺序走：

先确认 LCP 元素是谁
看 TTFB 是否过高
看 LCP 资源是否被晚发现
看关键 CSS/JS 是否阻塞
看图片格式、尺寸、优先级是否合理
看首屏阶段是否加载了太多无关脚本
再回头检查 CLS 和 INP 是否一起恶化

如果是“点击卡”：

打开 Performance 录制一次交互
找交互后的 Long Task
看是计算重、渲染重，还是第三方脚本重
拆任务、降渲染、移 Worker、做虚拟列表

如果是“页面乱跳”：

打开 Layout Shift 轨迹
定位发生偏移的节点
补尺寸、预留容器、避免上方插入
处理字体切换和广告位波动

总结

Core Web Vitals 的价值，不在于多了三个名词，而在于它给了前端性能优化一个更贴近用户体验的抓手：

LCP 解决“主要内容什么时候看到”
INP 解决“交互为什么不跟手”
CLS 解决“页面为什么乱跳”

真正做排查时，不要把它当成“跑个 Lighthouse 分数”的任务，而要把它当成一条完整链路：

指标采集
问题归因
代码修复
灰度验证
持续监控

最后给几个可执行建议，适合大多数中型前端项目直接落地：

先接入真实用户指标采集，不要只靠本地跑分
每个页面先找一个核心问题指标，别三头并进
首屏图、关键 CSS、主线程长任务，优先级最高
建立性能预算和 CI 检查，防止优化回退
第三方脚本按业务价值排序，别默认都值得首屏加载

边界条件也要说清楚：如果你的瓶颈在服务端 TTFB、接口串行、弱网环境或重 SSR 模板计算，仅靠前端层面的懒加载和分包，收益会很有限。这时候就该把优化范围扩展到服务端、缓存和基础设施。

如果你愿意把 Core Web Vitals 当成“性能排查地图”，而不是“评分系统”，很多复杂问题都会变得更容易拆解。

《前端性能实战：基于 Core Web Vitals 的页面加载优化与排查指南》

前端性能实战：基于 Core Web Vitals 的页面加载优化与排查指南

背景与问题

先看一眼：性能排查总流程

核心原理

Core Web Vitals 到底在衡量什么

1. LCP：用户什么时候“看到重点内容”

2. INP：页面能不能及时响应用户操作

3. CLS：为什么页面会“乱跳”

Core Web Vitals 与页面加载链路关系

现象复现：一个“看起来正常，其实指标很差”的页面

定位路径：不要一上来就改代码，先确认“慢在哪里”

第一层：用户真实数据

第二层：实验室数据

第三层：资源与主线程细节

实战代码：接入 web-vitals 采集真实指标

实战优化一：LCP 差，优先查首屏资源链路

典型症状

止血方案

1）给首屏图片更高优先级

2）避免首屏图片被懒加载

3）减少渲染阻塞

4）控制服务端响应时间

实战优化二：INP 差，核心是减少主线程长任务

典型症状

先看一个糟糕写法

优化思路

1）把重计算移出主线程

2）把大任务切片

3）避免无差别整树更新

实战优化三：CLS 差，先把“空间预留”做好

错误写法

正确写法

视频、广告、异步容器也一样

顶部通知不要硬插入文档流

一张图看懂三类问题与对应抓手

常见坑与排查

1. Lighthouse 分数还行，但用户仍然觉得慢

2. 首屏图明明压缩了，LCP 还是差

3. 我已经做了代码分包，为什么 INP 还是差

4. CLS 明明不高，但用户还是抱怨“页面乱”

5. 第三方脚本拖慢页面，但业务又不能下掉

安全/性能最佳实践

1）静态资源走 HTTPS 与强缓存

2）合理使用 preconnect

3）控制第三方脚本权限与时机

4）避免内联大脚本和大 JSON

5）建立性能预算

6）把性能检测接入 CI

一套我常用的排查顺序

总结

2）合理使用 `preconnect`