前端性能实战：基于 Core Web Vitals 的页面加载优化与监控体系搭建

前端性能这件事，很多团队一开始都在“凭感觉优化”：

页面首屏看起来慢，但说不清慢在哪
Lighthouse 跑分挺高，线上用户却一直反馈卡
做了图片压缩、代码拆包、CDN，效果还是不稳定
监控里只有接口耗时，没有“用户实际体验”的数据

我自己早期也踩过类似的坑：本地开发环境秒开，测试环境也还行，一到生产、尤其是中低端手机和弱网环境，页面就开始掉链子。后来真正把体系搭起来后，才发现性能优化不能只盯“资源体积”，而要围绕 Core Web Vitals 建立一套从指标、定位、优化到监控闭环的流程。

这篇文章不讲空泛原则，而是带你从实战角度走一遍：

Core Web Vitals 到底衡量什么
如何针对页面加载做有效优化
如何在前端项目里接入真实用户监控（RUM）
如何把优化与监控串成一个长期可维护的体系

背景与问题

为什么传统性能优化经常“做了很多，但效果一般”？

因为性能问题本质上分成两类：

实验室数据：比如 Lighthouse、DevTools Performance
真实用户数据：用户设备、网络、页面路径都不一样

实验室数据适合发现“理论瓶颈”，但无法完全代表真实访问体验。尤其是下面这些场景：

首页资源很多，但缓存命中率不错，首次访问慢、回访快
某些低端 Android 机型 CPU 很弱，JS 执行时间远大于下载时间
接口返回快，但页面布局抖动严重，用户仍然觉得“卡”
首屏已经显示出来了，但点击按钮半天没反应

所以，性能体系不能只看“加载完成没完成”，而是要看：

内容什么时候出现
页面什么时候稳定
用户什么时候能流畅交互

这就是 Core Web Vitals 的价值。

核心原理

Core Web Vitals 是什么

Core Web Vitals 是 Google 提出的用户体验核心指标，当前主要关注三个维度：

LCP（Largest Contentful Paint）
最大内容绘制时间，衡量“主要内容多久显示出来”
INP（Interaction to Next Paint）
交互到下次绘制的延迟，衡量“交互响应是否顺滑”
CLS（Cumulative Layout Shift）
累积布局偏移，衡量“页面是否乱跳”

如果你是做页面加载优化，最先碰到的一般是 LCP 和 CLS；如果页面交互复杂、JS 重，后面就会重点看 INP。

三个指标怎么理解

1. LCP：用户看到“主要内容”的速度

LCP 常见候选元素包括：

首屏大图
banner
大标题文本块
视频封面图

经验上：

优秀：<= 2.5s
待改进：2.5s ~ 4s
较差：> 4s

LCP 慢，通常不是单一原因，而是几类问题叠加：

HTML 返回慢
首屏资源下载慢
首屏图片太大
关键 CSS 阻塞渲染
JS 执行太重，主线程繁忙

2. INP：用户点了为什么没反应

INP 是对交互延迟的综合评估。比如：

点击按钮后，UI 很久才更新
输入框输入卡顿
打开弹窗有明显停顿

经验上：

优秀：<= 200ms
待改进：200ms ~ 500ms
较差：> 500ms

INP 差的典型原因：

长任务阻塞主线程
大量同步 JS 计算
事件回调做了太多事
React/Vue 大范围无意义重渲染

3. CLS：页面“跳来跳去”

CLS 是最容易被低估的指标。用户刚要点按钮，广告插进来，位置变了；图片还没加载，高度不确定，后面的内容被顶下去。

经验上：

优秀：<= 0.1
待改进：0.1 ~ 0.25
较差：> 0.25

CLS 常见来源：

图片/iframe 没有预留尺寸
异步插入广告、推荐位、弹窗
Web 字体切换导致文字重排
动画直接改动 top/left/height

指标与优化闭环

先看一张整体图，把“指标—瓶颈—优化—监控”串起来。

flowchart TD
    A[用户访问页面] --> B[采集 Core Web Vitals]
    B --> C{指标异常?}
    C -- 否 --> D[持续观察趋势]
    C -- 是 --> E[定位瓶颈]
    E --> F[LCP: 网络/资源/渲染]
    E --> G[INP: 主线程/长任务/事件处理]
    E --> H[CLS: 尺寸预留/异步插入/字体]
    F --> I[代码与资源优化]
    G --> I
    H --> I
    I --> J[灰度发布]
    J --> K[线上回收监控数据]
    K --> C

这张图想表达的重点很简单：不要把优化和监控分开做。只做优化，没有线上验证，很容易误判；只做监控，不做归因，数据也只是“看着着急”。

前置知识与环境准备

本文示例默认你具备这些基础：

会使用浏览器 DevTools
了解 HTTP 缓存、CDN、资源加载顺序
熟悉一个前端框架（React/Vue/原生都行）
能搭一个简单的 Node 服务

我们会用到：

web-vitals：采集核心指标
原生 sendBeacon：上报监控数据
一个简单 Node 接口：接收监控日志

安装依赖：

npm install web-vitals

核心原理：页面加载链路怎么影响 Core Web Vitals

很多时候大家优化性能会直接“压图片、拆包、开缓存”，但如果不先理解页面加载链路，很难判断哪个动作最值钱。

sequenceDiagram
    participant U as 用户浏览器
    participant S as 服务端
    participant C as CDN
    participant A as API

    U->>S: 请求 HTML
    S-->>U: 返回 HTML
    U->>C: 请求 CSS/JS/图片
    C-->>U: 返回静态资源
    U->>A: 请求首屏数据
    A-->>U: 返回接口数据
    U->>U: 解析 HTML/CSS/JS
    U->>U: 布局与绘制
    U->>U: 用户可见并可交互

影响 LCP 的关键路径

通常是：

HTML 到达浏览器
浏览器发现 LCP 资源
下载关键 CSS / 图片 / 字体
完成布局绘制

任何一个环节慢，LCP 都会变差。

影响 INP 的关键路径

通常是：

用户触发交互
事件处理函数执行
主线程清空阻塞任务
页面完成下次绘制

所以 INP 的优化重点常常不是“网络”，而是 主线程负载。

影响 CLS 的关键路径

通常是：

初始 DOM 渲染
异步资源或模块插入
重新布局导致元素位置变化

CLS 的核心不是“快不快”，而是“稳不稳”。

实战一：先把页面加载做对

这一节我们从 LCP 和 CLS 入手，先处理首屏加载问题。

1. 识别首屏关键资源

先明确谁是 LCP 元素。最常见方法：

Chrome DevTools -> Performance
Lighthouse 报告
实际页面观察首屏大元素

假设首页首屏是一个 Banner 图 + 主标题，那么页面结构可能像这样：

<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>性能优化示例</title>

    <link rel="preconnect" href="https://static.example.com" />
    <link rel="preload" as="image" href="https://static.example.com/banner.webp" />

    <style>
      body {
        margin: 0;
        font-family: Arial, sans-serif;
      }

      .hero {
        max-width: 960px;
        margin: 0 auto;
        padding: 24px;
      }

      .hero img {
        width: 100%;
        height: auto;
        display: block;
        aspect-ratio: 16 / 9;
        object-fit: cover;
      }

      .hero h1 {
        font-size: 36px;
        margin: 16px 0;
      }
    </style>
  </head>
  <body>
    <section class="hero">
      <img
        src="https://static.example.com/banner.webp"
        width="960"
        height="540"
        alt="首屏 Banner"
        fetchpriority="high"
      />
      <h1>基于 Core Web Vitals 的页面性能优化</h1>
      <p>让性能不再靠猜，而是有数据、有定位、有闭环。</p>
    </section>
  </body>
</html>

这里有几个关键点：

preconnect：提前建立连接
preload：让浏览器更早下载首屏图
fetchpriority="high"：告诉浏览器这是高优先级图片
width/height 和 aspect-ratio：防止布局抖动

这几个动作看起来普通，但对 LCP 和 CLS 都很有帮助。

2. 避免关键 CSS 被非关键资源拖慢

一个经典问题是：为了“工程化统一管理”，把所有 CSS 打成一个大文件，导致首屏样式也被拖住。

更好的方式是：

首屏关键样式内联
非首屏样式异步加载
大型组件样式按路由拆分

示例：

<link rel="preload" href="/styles/main.css" as="style" />
<link rel="stylesheet" href="/styles/main.css" media="print" onload="this.media='all'" />
<noscript><link rel="stylesheet" href="/styles/main.css" /></noscript>

注意：这种异步加载 CSS 的方式要谨慎使用，尤其是首屏依赖的样式不能延后，否则反而会引发 FOUC（无样式闪烁）。我的经验是：

首屏骨架和基础布局：内联
详情区、评论区、推荐模块样式：异步

3. 降低首屏 JavaScript 压力

如果页面还没渲染完，主线程先去执行大量 JS，LCP 和 INP 都会受影响。

常见优化手段：

路由级代码拆分
延后非关键模块初始化
减少首屏 hydration 压力
能服务端输出的内容，尽量不要全靠客户端拼

例如把“推荐列表”延迟初始化：

document.addEventListener('DOMContentLoaded', () => {
  const critical = () => {
    console.log('首屏关键逻辑已完成');
  };

  const nonCritical = () => {
    import('./recommend.js')
      .then((mod) => mod.initRecommend())
      .catch((err) => console.error('推荐模块加载失败', err));
  };

  critical();

  if ('requestIdleCallback' in window) {
    requestIdleCallback(nonCritical, { timeout: 2000 });
  } else {
    setTimeout(nonCritical, 500);
  }
});

这样做的核心思路是：把“必须马上做”和“可以晚一点做”分开。

实战二：接入 Core Web Vitals 监控

优化只是第一步。没有监控，过一段时间改版、加埋点、接新 SDK，性能很容易反弹。

下面我们搭一个最小可运行的监控方案。

1. 前端采集指标

创建 rum.js：

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

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

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/monitor/web-vitals', body);
  } else {
    fetch('/monitor/web-vitals', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body,
      keepalive: true,
    }).catch((err) => {
      console.error('上报失败', err);
    });
  }
}

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

在页面入口引入：

import './rum.js';

为什么建议用 `sendBeacon`

因为它适合页面卸载时发送少量数据：

不阻塞跳转
成功率通常比普通异步请求更高
对用户体验影响更小

2. 服务端接收数据

下面用一个最简单的 Node + Express 示例来接收日志。

const express = require('express');

const app = express();
app.use(express.json({ limit: '100kb' }));

app.post('/monitor/web-vitals', (req, res) => {
  const metric = req.body;

  console.log('收到性能指标:', metric);

  // 生产环境中可写入日志系统、消息队列或时序数据库
  // 例如 Kafka / ClickHouse / Elasticsearch / Prometheus 等

  res.status(204).end();
});

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

启动：

node server.js

3. 增强上报上下文，便于排查

只上报指标值是不够的。真正排查时，你会发现下面这些上下文非常重要：

页面路由
网络类型
设备内存
是否首访
是否命中缓存
用户登录态
发布版本号
采样比例

可以这样扩展：

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

function getExtraContext() {
  const nav = navigator;
  const conn = nav.connection || {};

  return {
    url: location.href,
    pathname: location.pathname,
    screen: `${window.screen.width}x${window.screen.height}`,
    language: nav.language,
    online: nav.onLine,
    deviceMemory: nav.deviceMemory || null,
    hardwareConcurrency: nav.hardwareConcurrency || null,
    networkType: conn.effectiveType || 'unknown',
    rtt: conn.rtt || null,
    downlink: conn.downlink || null,
    appVersion: '1.3.0',
    sampleRate: 1,
  };
}

function report(metric) {
  const payload = {
    ...getExtraContext(),
    metric: {
      name: metric.name,
      value: metric.value,
      delta: metric.delta,
      rating: metric.rating,
      id: metric.id,
    },
    timestamp: Date.now(),
  };

  const body = JSON.stringify(payload);

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/monitor/web-vitals', body);
  } else {
    fetch('/monitor/web-vitals', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body,
      keepalive: true,
    }).catch(() => {});
  }
}

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

4. 建立性能分层看板

监控不是把数据一股脑存起来就完了，最好从一开始就按维度分层：

总体趋势：LCP/INP/CLS 的 p75
页面维度：首页、详情页、活动页
设备维度：Android / iPhone / PC
网络维度：4g / 3g / wifi
版本维度：发布前后对比
地区维度：不同机房、不同 CDN 节点

你真正要盯的，通常不是平均值，而是 P75。因为平均值太容易被少数极端情况稀释，不能代表大多数用户体验。

监控体系结构设计

如果项目已经进入多人协作阶段，建议不要把性能监控写成“零散埋点”，而是做成统一模块。

flowchart LR
    A[页面应用] --> B[性能采集 SDK]
    B --> C[数据清洗与采样]
    C --> D[上报网关]
    D --> E[日志/消息队列]
    E --> F[存储与聚合]
    F --> G[看板]
    F --> H[告警系统]
    G --> I[性能治理]
    H --> I

这个结构的价值

采集逻辑统一，避免每个业务自己写一套
可以做采样、脱敏、字段标准化
支持按页面、版本、设备统一看趋势
可以接告警，在性能回退时尽快发现

实战三：针对典型指标问题做优化

下面按指标拆分常见处理方式。

1. LCP 优化清单

方法一：提升 HTML 到达速度

如果服务端 HTML 响应慢，后面一切优化都很难救回来。

可以做：

启用 CDN 边缘缓存
SSR 接口聚合，减少首屏阻塞请求
开启压缩：Gzip/Brotli
降低模板渲染耗时

Nginx 压缩示例：

gzip on;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json text/xml application/xml;

方法二：优化首屏图片

首屏图片经常是 LCP 最大头。

建议：

优先使用 WebP / AVIF
根据容器输出合适尺寸，不要原图直传
配置 srcset 和 sizes
对真正首屏图加 preload 或 fetchpriority="high"

示例：

<img
  src="banner-960.webp"
  srcset="banner-480.webp 480w, banner-960.webp 960w, banner-1440.webp 1440w"
  sizes="(max-width: 768px) 100vw, 960px"
  width="960"
  height="540"
  alt="横幅图"
  fetchpriority="high"
/>

方法三：减少渲染阻塞资源

检查：

是否有过多同步脚本
是否把第三方 SDK 放在头部阻塞
是否把字体文件当首屏强依赖

脚本建议：

<script src="/js/app.js" defer></script>
<script src="/js/analytics.js" async></script>

defer：适合依赖 DOM 顺序的主脚本
async：适合统计类、独立脚本

2. INP 优化清单

方法一：识别长任务

可以先观察 Long Task。浏览器提供了 PerformanceObserver：

if ('PerformanceObserver' in window) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log('Long Task:', {
        name: entry.name,
        duration: entry.duration,
        startTime: entry.startTime,
      });
    }
  });

  observer.observe({ type: 'longtask', buffered: true });
}

如果你看到大量超过 50ms 的任务，说明主线程被占满了。

方法二：切碎大任务

错误写法：

button.addEventListener('click', () => {
  const result = [];
  for (let i = 0; i < 1000000; i++) {
    result.push(i * i);
  }
  render(result);
});

改进写法，分片执行：

button.addEventListener('click', () => {
  const result = [];
  let i = 0;
  const total = 1000000;
  const chunkSize = 5000;

  function processChunk() {
    const end = Math.min(i + chunkSize, total);
    for (; i < end; i++) {
      result.push(i * i);
    }

    if (i < total) {
      setTimeout(processChunk, 0);
    } else {
      render(result);
    }
  }

  processChunk();
});

如果计算特别重，更适合放到 Web Worker。

方法三：减少无意义重渲染

框架项目里，INP 很差常常不是事件本身，而是事件触发后引发大面积组件更新。

建议：

合理拆分状态
用 memo / computed / cache 减少重复计算
避免列表全量重渲染
大列表使用虚拟滚动

3. CLS 优化清单

方法一：所有媒体元素预留尺寸

错误示例：

<img src="/images/card.png" alt="卡片图" />

正确示例：

<img src="/images/card.png" width="320" height="180" alt="卡片图" />

配合 CSS：

img {
  max-width: 100%;
  height: auto;
}

方法二：异步内容预留占位空间

比如广告位、推荐位、评论模块，哪怕数据还没返回，也要先占位置。

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

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

方法三：动画尽量使用 transform

不推荐：

.card {
  position: relative;
  transition: top 0.3s ease;
}
.card:hover {
  top: -10px;
}

常见坑与排查

这一部分我尽量写得实战一点，因为很多问题不是“不会优化”，而是“误判了问题”。

坑 1：Lighthouse 很高，线上依旧很慢

原因

Lighthouse 是实验室环境
线上用户设备弱、网络差
缓存命中和真实链路不同
第三方脚本线上才真正生效

排查方法

对比实验室数据和 RUM 数据
看 p75，而不是只看单次跑分
按设备、网络、路由拆分

经验建议：Lighthouse 用来找方向，RUM 用来做决策。

坑 2：做了懒加载，LCP 反而更差

原因

把首屏大图也懒加载了，导致浏览器晚发现、晚下载。

错误示例：

<img src="/banner.webp" loading="lazy" alt="banner" />

如果它是 LCP 图，应该改成：

<img src="/banner.webp" fetchpriority="high" alt="banner" />

原则

首屏关键资源不要盲目懒加载
懒加载适合非首屏内容

坑 3：CLS 明明不高，用户还觉得页面乱跳

原因

有些布局变化发生在用户交互预期内，CLS 不一定完全体现“主观不适”；另外也可能是局部模块频繁闪动。

排查方法

打开 DevTools Performance 的 Experience 视图
观察 Layout Shift 记录
结合录屏或 session replay 分析

坑 4：INP 只在部分机型特别差

原因

这通常意味着不是“功能错了”，而是“CPU 不够”。

常见场景：

中低端安卓设备 JS 执行慢
某些国产浏览器内核表现差
页面注入多个第三方 SDK

排查方法

按 deviceMemory、hardwareConcurrency 分组
看长任务分布
看第三方脚本执行时长

坑 5：监控数据很多，但没人真正用

原因

指标太多，没有主线
没有告警阈值
没有版本对比
数据和发布流程脱节

解决建议

至少建立三条规则：

每次发布后，观察核心页面 p75
指标超过阈值自动告警
重大改版前后必须做性能对比

安全/性能最佳实践

性能监控本身也需要约束，不然容易变成“为了监控而拖慢页面”。

1. 监控 SDK 自己要足够轻

建议：

控制体积，尽量几 KB 级别
不要引入重型依赖
不阻塞主线程
失败可降级，不影响业务逻辑

2. 上报要做采样

不是所有请求都必须全量上报。尤其高流量页面，建议采样。

function shouldSample(rate = 0.1) {
  return Math.random() < rate;
}

if (shouldSample(0.1)) {
  import('./rum.js');
}

这样能显著减少：

带宽消耗
后端存储压力
聚合分析成本

3. 注意隐私与数据脱敏

监控数据里不要直接传：

手机号
身份证号
明文 token
用户输入内容
完整敏感 URL 参数

可以对 URL 做裁剪：

function safePath(url) {
  try {
    const u = new URL(url);
    return `${u.origin}${u.pathname}`;
  } catch {
    return location.pathname;
  }
}

4. 给第三方脚本设边界

很多线上性能问题，不是业务代码，而是：

统计 SDK
广告脚本
AB 测试平台
在线客服
地图/播放器 SDK

建议：

非关键脚本尽量延后
评估每个第三方脚本收益
定期审计“不再使用的 SDK”
对第三方资源设置超时和兜底

5. 建立性能预算

没有预算，优化很容易失控。可以设置：

首屏 JS <= 200KB gzip
首屏图片 <= 150KB
首页 LCP p75 <= 2.5s
CLS p75 <= 0.1
INP p75 <= 200ms

性能预算不是教条，但它能帮团队在需求迭代中守住底线。

逐步验证清单

如果你准备在项目里实际落地，我建议按下面顺序推进。

第一步：先看现状

跑 Lighthouse
用 DevTools 看首屏 waterfall
找出 LCP 元素
看是否存在明显 CLS
看主线程是否有长任务

第二步：优先处理高收益项

首屏图格式与尺寸优化
关键 CSS 提前
非关键 JS 延后
所有媒体元素补齐尺寸
去掉首屏不必要第三方脚本

第三步：接入线上监控

接入 web-vitals
加路由、版本、设备、网络上下文
建 p75 看板
设置异常告警

第四步：把性能纳入发布流程

发布前做性能基线检查
发布后观察指标波动
回归问题时能按版本快速定位

一套可执行的落地策略

如果你带的是一个中型前端项目，我建议不要想着“一周内把性能体系做完”，更现实的方式是分阶段：

阶段一：先把最小闭环跑通

目标：

接入 LCP / INP / CLS 采集
搭一个接收接口
能看到按页面维度的 p75

阶段二：完成高频问题治理

目标：

首屏资源优先级梳理
图片与 CSS 优化
长任务监控
组件渲染热点治理

阶段三：工程化和制度化

目标：

做统一 SDK
做告警
做版本对比
做性能预算门禁

说白了，性能治理不是一次性项目，而是一个持续工程。

总结

基于 Core Web Vitals 做前端性能优化，我认为最重要的不是记住多少“优化技巧”，而是建立这条主线：

用 LCP、INP、CLS 定义用户体验
从页面加载链路和主线程负载定位瓶颈
优先优化首屏关键资源、交互长任务、布局稳定性
接入真实用户监控，按页面/设备/网络看 p75
把性能纳入发布和回归流程，形成闭环

如果只给你几个最可执行的建议，我会建议你先做这 5 件事：

找出首页 LCP 元素，确保它不是懒加载
给所有图片和异步模块预留尺寸
延后非关键 JS 和第三方脚本
接入 web-vitals 做真实用户监控
用版本维度对比性能回退

最后再强调一个边界条件：不是所有页面都值得做极致优化。对低流量后台页面，成本收益可能不高；但对首页、详情页、活动页、转化页，性能往往直接影响留存和转化，这些页面非常值得系统化投入。

性能这件事，最怕的是“知道重要，但总是最后再做”。真正有效的方法，是把它做成日常工程的一部分。只要闭环建立起来，后面每一次优化都会更有把握。

《前端性能实战：基于 Core Web Vitals 的页面加载优化与监控体系搭建》

前端性能实战：基于 Core Web Vitals 的页面加载优化与监控体系搭建

背景与问题

为什么传统性能优化经常“做了很多，但效果一般”？

核心原理

Core Web Vitals 是什么

三个指标怎么理解

1. LCP：用户看到“主要内容”的速度

2. INP：用户点了为什么没反应

3. CLS：页面“跳来跳去”

指标与优化闭环

前置知识与环境准备

核心原理：页面加载链路怎么影响 Core Web Vitals

影响 LCP 的关键路径

影响 INP 的关键路径

影响 CLS 的关键路径

实战一：先把页面加载做对

1. 识别首屏关键资源

2. 避免关键 CSS 被非关键资源拖慢

3. 降低首屏 JavaScript 压力

实战二：接入 Core Web Vitals 监控

1. 前端采集指标

为什么建议用 sendBeacon

2. 服务端接收数据

3. 增强上报上下文，便于排查

4. 建立性能分层看板

监控体系结构设计

这个结构的价值

实战三：针对典型指标问题做优化

1. LCP 优化清单

方法一：提升 HTML 到达速度

方法二：优化首屏图片

方法三：减少渲染阻塞资源

2. INP 优化清单

方法一：识别长任务

方法二：切碎大任务

方法三：减少无意义重渲染

3. CLS 优化清单

方法一：所有媒体元素预留尺寸

方法二：异步内容预留占位空间

方法三：动画尽量使用 transform

常见坑与排查

坑 1：Lighthouse 很高，线上依旧很慢

原因

排查方法

坑 2：做了懒加载，LCP 反而更差

原因

原则

坑 3：CLS 明明不高，用户还觉得页面乱跳

原因

排查方法

坑 4：INP 只在部分机型特别差

原因

排查方法

坑 5：监控数据很多，但没人真正用

原因

解决建议

安全/性能最佳实践

1. 监控 SDK 自己要足够轻

2. 上报要做采样

3. 注意隐私与数据脱敏

4. 给第三方脚本设边界

5. 建立性能预算

逐步验证清单

第一步：先看现状

第二步：优先处理高收益项

第三步：接入线上监控

第四步：把性能纳入发布流程

一套可执行的落地策略

阶段一：先把最小闭环跑通

阶段二：完成高频问题治理

阶段三：工程化和制度化

总结

为什么建议用 `sendBeacon`