写在前面
很久以前，我们用
window.onload和“白屏时间”来衡量性能。但在单页应用（SPA）和骨架屏盛行的今天，这些老指标已经失效了。页面“加载完”了（Spinning loader 消失），但内容可能还没出来；内容出来了，可能点不动；点得动了，广告突然弹出来把你正在看的文章挤跑了。2020 年，Google 推出了 Web Vitals，重新定义了用户体验的度量衡。
这一节，我们将手中的“秒表”换成精密的“心电图机”，不仅要让页面跑得快（LCP），还要跑得稳（CLS），更要反应灵敏（INP）。
一、 核心指标三巨头：LCP、INP 与 CLS
Google 在几十个性能指标中，钦点了三个作为 Core Web Vitals (CWV) 。这不仅关乎用户体验，还直接影响 SEO 排名。
1.1 LCP (Largest Contentful Paint) —— 视网膜的愉悦
- 含义： 视口内最大的那块内容（通常是大图或 H1 标题）渲染完成的时间。
- 为什么不用
load事件？ 因为load触发时，屏幕可能还是白的，或者只有一个 Loading 圈。用户不在乎 Loading 圈，用户在乎的是看到正文。 - 及格线： 2.5 秒以内。
1.2 INP (Interaction to Next Paint) —— 指尖的快感
- 注意： 以前叫 FID (First Input Delay)，2024 年 3 月起已被 INP 正式取代。架构师必须更新知识库！
- 含义： 并不是测你第一次点击有多快，而是测全生命周期内，页面对用户操作（点击、按键）的响应延时（从点击到下一帧绘制的时间）。
- 及格线： 200 毫秒以内。
- 底层逻辑： 如果 INP 高，说明主线程被长任务（Long Task）堵死了（回顾第四篇 Event Loop）。
1.3 CLS (Cumulative Layout Shift) —— 视觉的稳定
- 含义： 累积布局偏移。通俗说就是“页面跳不跳”。
- 场景： 你正要点“取消”，突然顶部加载出来一张广告图，把你挤到了下面的“确认”按钮上。这是最让用户抓狂的体验。
- 及格线： 0.1 分以下。
二、 实验室数据 vs 真实用户数据：你被 Lighthouse 骗了吗？
很多开发者在本地跑 Lighthouse 拿了 100 分，上线后用户却骂声一片。为什么？
2.1 Lab Data (实验室数据 / 合成监控)
- 工具： Lighthouse, Chrome DevTools Performance。
- 环境： 你的高配 MacBook Pro + 公司千兆光纤。
- 特点： 环境可控，适合调试，但不代表真实体验。
2.2 Field Data (现场数据 / 真实用户监控 RUM)
- 工具： Chrome UX Report (CrUX), 埋点上报。
- 环境： 用户的红米手机 + 地铁里的弱网 4G。
- 特点： 这才是真相。
架构师策略： “用 Lab Data 治未病，用 Field Data 治已病。” 你需要在 CI/CD 流水线中跑 Lighthouse 守住底线，同时在生产环境接入 RUM (Real User Monitoring) 收集真实用户的 Web Vitals。
// 生产环境监控实战：使用 web-vitals 库
import { onLCP, onINP, onCLS } from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
// 使用 navigator.sendBeacon 保证页面关闭时也能发送
navigator.sendBeacon('/analytics', body);
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
三、 全链路优化实战：串联前四篇的知识
现在，我们拿着这三个指标，回顾前四节的内容，看看如何对症下药。
3.1 优化 LCP (加载速度) —— 考验“管道”与“守门”
LCP 慢，通常是因为资源下不来，或者渲染被阻塞。
-
回顾第一篇 (网络): 升级 HTTP/3 (QUIC) ，消除队头阻塞，加速握手。
-
回顾第二篇 (资源):
- CDN 预连接:
<link rel="preconnect" ...> - 关键资源预加载: 对 LCP 图片使用
<link rel="preload" as="image" ...>。 - Fetch Priority:
<img src="hero.jpg" fetchpriority="high">。
- CDN 预连接:
3.2 优化 INP (交互响应) —— 考验“心脏”
INP 差，说明主线程太忙，Event Loop 转不动了。
-
回顾第四篇 (Event Loop):
- 切片: 只有把长任务切碎（Time Slicing），主线程才有空隙去响应用户的点击。
- Web Workers: 把繁重的计算（如加密、大文件解析）扔出主线程。
- 避免 Layout Thrashing: 别在点击事件里强制读取
offsetWidth导致同步重排。
3.3 优化 CLS (视觉稳定) —— 考验“画师”
CLS 高，是因为画师在画布上反复涂改。
-
回顾第三篇 (渲染):
- 定尺寸: 所有的
<img>和<video>必须写死width和height属性（或 CSS aspect-ratio），先占位，后加载。 - 字体抖动: 使用
font-display: swap或optional，避免 FOIT (Flash of Invisible Text)。 - 动画合成: 坚持使用
transform做动画，避免触发布局变化。
- 定尺寸: 所有的
四、 性能文化的建设：从“突击队”到“正规军”
作为架构师，最难的不是自己修 Bug，而是防止别人写 Bug。
4.1 性能预算 (Performance Budget)
在 Webpack/Vite 配置中设置阈值：
- JS Bundle 体积不得超过 200KB。
- 关键 CSS 不得超过 50KB。 一旦超标，构建直接失败。
4.2 自动化守门员
在 GitHub Actions 或 Jenkins 中集成 Lighthouse CI。 如果是 PR 导致 Performance 分数下降了 5 分，禁止 Merge。
结语：快，是做出来的，更是守出来的
性能优化不是一种“魔法”，而是一门“工程学”。 它需要你理解从 TCP 包的发送，到 CPU 的调度，再到像素合成的每一个环节。Web Vitals 就是这套复杂系统的仪表盘。
至此，第五阶段《浏览器运行原理 + 前端网络协议与请求模型》 圆满结束。 我们深入了管道，拜访了守门员，观摩了画师，解剖了心脏，最后拿起了度量尺。
现在，你的前端应用已经跑得飞快了。但是，代码写得快、跑得快就够了吗？如果代码乱得像一团麻，或者上线就崩，再快也是徒劳。
