写在前面

很久以前，我们用 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">。

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 就是这套复杂系统的仪表盘。

至此，第五阶段《浏览器运行原理 + 前端网络协议与请求模型》 圆满结束。 我们深入了管道，拜访了守门员，观摩了画师，解剖了心脏，最后拿起了度量尺。

现在，你的前端应用已经跑得飞快了。但是，代码写得快、跑得快就够了吗？如果代码乱得像一团麻，或者上线就崩，再快也是徒劳。

写在前面

你是否遇到过这种灵异现象：

• 写了一个 while(true)，结果页面按钮点不动，Gif 图不转了，甚至浏览器弹窗提示“页面无响应”。
• 明明设置了 setTimeout(fn, 0)，为什么还是比 Promise.then 慢？
• React 的并发模式（Concurrent Mode）到底在切割什么？

这一切的答案都在 Event Loop 里。

JavaScript 之所以设计成单线程，是为了避免复杂的 DOM 并发操作（想象一下两个线程同时修改同一个 DOM）。但单线程意味着“排队”。架构师的艺术，就是**“插队”的管理学**——决定谁是 VIP（微任务），谁是普通号（宏任务），以及何时让显示器刷新（渲染时机）。

---

一、 单线程的谎言：浏览器其实是多线程的

虽然我们常说 JS 是单线程的，但这并不代表浏览器是傻瓜。 JS 引擎（如 V8）确实只有一个主线程（Main Thread），既要跑 JS，又要算 Layout，还要负责 Paint。

但是，浏览器提供了强大的 Web APIs 作为后援团，它们运行在其他线程：

• 网络线程： 负责 fetch / XHR。
• 定时器线程： 负责 setTimeout 计时。
• 合成线程： 负责 GPU 绘制。

事件循环的本质： 当 fetch 回来数据，或者定时器倒计时结束，后台线程会把回调函数扔进一个任务队列（Task Queue） 。主线程就像一个永不知疲倦的工人，不断地从队列里取任务执行。

---

二、 阶级森严：宏任务与微任务的博弈

并不是所有任务都是平等的。Event Loop 维护了两个队列，它们的优先级天差地别。

2.1 宏任务 (Macrotask / Task)

这是普通公民。

• 成员： script (整体代码), setTimeout, setInterval, setImmediate (Node), I/O, UI Rendering。
• 规则： 每次 Loop 只取一个 执行。

2.2 微任务 (Microtask)

这是 VIP 贵宾。

• 成员： Promise.then, process.nextTick (Node), MutationObserver, queueMicrotask。
• 规则： 在当前宏任务结束之后，清空整个微任务队列，然后才去渲染或执行下一个宏任务。

2.3 致命的陷阱：微任务死循环

请看这段代码：

function killBrowser() {
  Promise.resolve().then(killBrowser); // 无限递归微任务
}
killBrowser();

结果： 页面彻底卡死，甚至无法渲染。 原因： 因为微任务队列会在渲染之前清空。如果你不断向微任务队列加东西，主线程永远走不到“渲染”那一步，也永远走不到下一个“宏任务”。

---

三、 心跳的节奏：渲染时机与 requestAnimationFrame

很多开发者误以为 setTimeout(fn, 0) 是最快的。其实不然。 在 Event Loop 的一轮循环中，渲染（Update the Rendering） 是一个可选步骤。

3.1 浏览器的 60Hz 节奏

通常屏幕刷新率是 60Hz（16.6ms 一帧）。浏览器会尽量在这个节奏下进行渲染。 流程如下：

1. 执行一个宏任务（Task）。

2. 执行并清空所有微任务（Microtasks）。

3. 判断是否到了渲染时机？

   • 如果离上次渲染还没过 16ms，跳过。
   • 如果到了，执行渲染流水线（Style -> Layout -> Paint）。

4. 回到步骤 1。

3.2 requestAnimationFrame (rAF)

它是专门为动画设计的。它不在宏任务队列，也不在微任务队列。它运行在 “渲染步骤之前” 。

• setTimeout 动画： 可能在第 5ms 执行，也可能在第 20ms 执行，容易导致丢帧（Jank）。
• rAF 动画： 浏览器保证在每一次绘制每一帧之前执行，完美同步刷新率。

---

四、 架构师的手段：时间切片 (Time Slicing)

理解了 Event Loop，我们就能解决前端最大的性能难题：长任务 (Long Task) 。

假设你需要处理 10 万条数据。

// 阻塞主线程 2秒，页面假死
data.forEach(item => process(item));

4.1 方案一：利用宏任务切片

我们可以把 10 万次计算，拆分成 1000 个小任务，每个任务处理 100 条。

function processChunk() {
  // 处理 100 条...
  if (hasMore) {
    setTimeout(processChunk, 0); // 让出主线程
  }
}

原理： setTimeout 把控制权交还给浏览器，浏览器有机会去排版、渲染、响应点击，然后再回来执行下一个 chunk。

4.2 方案二：React Fiber 的智慧 (MessageChannel)

React Fiber 架构的核心就是时间切片。它利用 MessageChannel（宏任务）来实现比 setTimeout 更高优先级的调度，在浏览器空闲时执行 Diff 算法，一有用户输入马上打断。

4.3 方案三：requestIdleCallback

这是处理“不重要任务”的神器。

requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    // 只有在浏览器真的没事干（发呆）的时候，才执行这里
    doLowPriorityWork();
  }
});

适用场景： 发送埋点数据、预加载资源。

---

五、 现代异步模型：Async/Await 的本质

到了 ES2017，我们有了 async/await。看起来像同步代码，其实它只是 Generator + Promise 的语法糖。

async function foo() {
  console.log(1);
  await bar(); // 这一行相当于 Promise.resolve(bar()).then(...)
  console.log(2); // 这一行及以后的代码，都被扔进了微任务队列！
}

架构启示： 不要滥用 await 串行。

//  慢：串行等待，总耗时 2s
await getUser();
await getPosts();

//  快：并发执行，总耗时 1s
const userPromise = getUser();
const postsPromise = getPosts();
await Promise.all([userPromise, postsPromise]);

对于架构师来说，并发控制（如 p-limit 限制并发数）是基于 Event Loop 之上的高级艺术。

---

结语：让心脏强健地跳动

Event Loop 是前端架构的心跳机制。

• 微任务 适合处理高优先级的状态更新（如 Vue 的 nextTick）。
• 宏任务 适合拆解耗时的计算逻辑。
• rAF 是动画的唯一真神。
• Web Workers 是真正跳出 Event Loop，开启多线程并行计算的“体外心脏”（我们将在下一节稍作提及）。

掌握了这些，你就掌握了控制时间的魔法。

Next Step: 至此，我们理解了网络管道、资源守门、画师渲染和心脏调度。 那么，如何用一套科学的指标体系来衡量这一切的综合表现？如何向老板证明你的优化提升了用户体验？ 下一节，我们将迎来本阶段的终章—— 《第五篇：综合——架构师的度量尺：Web Vitals 性能指标体系与全链路优化实战》

写在前面

许多前端优化手段（比如 Preload, Prefetch, HTTP Cache）之所以经常失效，是因为开发者把浏览器当成了一个黑盒。

你是否遇到过：明明配置了强缓存，为什么 Service Worker 还是拦截了请求？明明加了 async，为什么脚本还是阻塞了 LCP 图片的加载？

本篇我们将拆解浏览器的资源加载模型（Resource Loading Model） 。在这个模型中，缓存不仅仅是 Cache-Control，DNS 不仅仅是域名解析，而请求优先级则是控制渲染顺序的终极权杖。

---

一、 纵深防御：四级缓存体系的决策顺序

当浏览器发起一个请求时（比如 GET /style.css），它绝不会直接发给网络。它会按顺序询问四位“守门员”。这个顺序至关重要，决定了你的缓存策略是否生效。

1.1 第一道门：Service Worker (可编程代理)

这是浏览器暴露给开发者的最大权限。

• 机制： SW 是运行在浏览器后台的独立线程。它拦截所有网络请求。
• 特权： 即使网络断开，或者服务器返回 500，SW 也可以直接返回缓存的内容。
• 架构意义： 它是实现 离线优先 (Offline First) 应用的基石。如果你的 SW 逻辑写得有问题（比如不更新缓存），那么后面所有的 HTTP 缓存策略都会失效。

1.2 第二道门：Memory Cache (短期记忆)

• 机制： 浏览器内存中的缓存。
• 特点： 极快，但易失。 当你关闭 Tab 页，缓存即清空。
• 场景： 页面上引入了两次相同的 <img src="logo.png">，第二次请求直接从 Memory Cache 读取，耗时 0ms。这通常由浏览器的 Preloader 自动管理，开发者很难干预。

1.3 第三道门：Disk Cache (HTTP Cache - 长期记忆)

这是我们最熟悉的领域，也是硬盘上的缓存。

• 强缓存 (Strong Cache): Cache-Control: max-age=31536000。浏览器根本不向服务器发送请求，直接返回 200 (from disk cache)。
• 协商缓存 (Negotiated Cache): ETag / Last-Modified。浏览器发送请求询问：“这文件过期了吗？”服务器回答：“没过期 (304 Not Modified)”。
• 架构陷阱： 千万不要给 index.html 设置强缓存！否则用户永远看不到新版本。

1.4 第四道门：Push Cache (HTTP/2 - 昙花一现)

这是 HTTP/2 连接中的缓存。它的生命周期仅限于当前的传输连接。由于兼容性和实现复杂性问题，目前在 Chrome 中很少被利用，架构设计时可忽略。

---

二、 隐形的时间偷窃者：DNS 解析与连接复用

缓存没命中？那就必须联网了。但联网的第一步不是发数据，而是“找路”。

2.1 DNS 的代价

将 www.google.com 转换为 142.250.xxx.xxx 需要时间。通常是 20ms - 100ms，移动端甚至更久。 如果你的页面资源分散在 5 个不同的 CDN 域名上，光是 DNS 解析就要浪费几百毫秒。

2.2 架构师的预判：Resource Hints

浏览器很聪明，但它不能预测未来。架构师需要通过“暗示”来告诉浏览器。

• dns-prefetch: “浏览器，待会儿我要用这个域名，你先帮我查查 IP。”

  <link rel="dns-prefetch" href="//third-party-analytics.com">
  

  适用场景： 不确定是否会用到，但解析一下不花钱的第三方资源（如埋点）。

• preconnect: “浏览器，不仅查 IP，把 TCP 握手和 TLS 握手也做完！”

  <link rel="preconnect" href="https://cdn.mysite.com" crossorigin>
  

  适用场景： 确定马上就要用的关键 CDN 域名。警告： 不要滥用。保持开放的 Socket 连接是很消耗资源的。

---

三、 调度的艺术：请求优先级 (Priority) 与关键渲染路径

这是本篇的核心。 浏览器虽然是并发请求（H2/H3），但带宽是有限的。浏览器必须给每个请求打上标签：Highest, High, Medium, Low, Lowest。

3.1 浏览器的默认分级逻辑 (Chrome 为例)

• Highest: HTML、CSS（关键渲染路径）、字体。
• High: 预加载资源 (Preload)、视口内的图片 (LCP Candidate)、Script (如果没加 async/defer)。
• Medium/Low: async/defer 的脚本。
• Lowest: 视口外的图片、prefetch 的资源。

3.2 架构师的微操：fetchpriority

以前，我们很难干预这个顺序。现在，我们有了 Priority Hints。

场景一：拯救 LCP (最大内容绘制) 浏览器默认会给图片较低的优先级。如果你的一张大图是首屏的核心（LCP），你应该手动提权：

<img src="hero.jpg" fetchpriority="high" alt="Hero">

这能让 LCP 指标提升 20% 以上。

场景二：降级非关键脚本 轮播图的 JS 逻辑、第三方的广告脚本，不应该抢占带宽。

<script src="carousel.js" fetchpriority="low"></script>

---

四、 综合实战：设计完美的加载瀑布流

结合缓存、DNS 和优先级，一个完美的资源加载模型应该是这样的：

1. HTML (入口):

   • 缓存: Cache-Control: no-cache (必须走协商缓存，保证版本更新)。
   • 预连接: 头部加入 <link rel="preconnect" href="cdn.com">。

2. CSS/JS (静态资源):

   • 文件名: 带 Hash 指纹 (main.a1b2c3.js)。
   • 缓存: max-age=1年, immutable (永久强缓存)。
   • 优先级: 关键 CSS 内联或 High 优先级；非关键 JS 使用 defer 降级。

3. LCP 图片:

   • 优先级: fetchpriority="high"。
   • 预加载: <link rel="preload" as="image"> (防止被 CSS 背景图深埋)。

4. API 请求:

   • 时机: 尽量在 JS 执行早期发起，或者利用 React Server Components (RSC) 在服务端直接获取，避免客户端的“请求瀑布流”。

---

结语

浏览器不再是黑盒。它有着严格的等级制度和晋升机制。 作为架构师，你的任务不是简单地把文件扔给浏览器，而是要像指挥交通一样，规划好每一比特数据的 流向（DNS）、车道（优先级）和停车场（缓存） 。

Next Step: 资源已经顺利通过了检查，进入了浏览器的内存。接下来，这些文本格式的 HTML、CSS 代码，是如何在几毫秒内变成屏幕上绚丽的像素的？ 下一节，我们将进入渲染引擎的内部—— 《第三篇：画师——像素的旅程：关键渲染路径 (CRP) 与分层合成机制》 。

一、 观察者 vs 发布订阅，别再傻傻分不清 虽然这两个模式长得很像，但在架构设计中，它们的应用场景截然不同。 1.1 观察者模式 (Observer Pattern) 角色： Subject（被观察

AI快速的发展中，可能在未来前后端岗位会发生，但试问一下，如果真到了那个时候，波及到的不会只有互联网行业，而是我们的生活方式同样会发生变化，我们唯有随需而变。