Appearance
Web 性能工程：加载、渲染、交互与 Core Web Vitals
> 视频入口：B站合集《前端全链路：从浏览器基础到现代生态》上传并核验后回填正式链接。 > 本文是 EP27 的博客深讲版，包含视频主线，但比视频补充更多机制、流程图、边界判断和排查清单。
这篇文章解决什么问题
这期解释 Web 性能不是单个分数，而是加载、渲染和交互组成的用户体验链路。
这一篇的中心问题可以概括成：Web 性能如何从加载、渲染、交互和指标四个角度定位？
关键词：Core Web Vitals、LCP、INP、CLS、Waterfall、bundle、cache、layout、paint、composite
视频主线回顾
1. 加载路径
Network Waterfall 帮助定位关键资源和缓存问题。
2. 渲染路径
样式、布局、绘制和合成共同决定画面稳定性。
3. 交互响应
Long Task 会阻塞主线程和用户输入。
4. Core Web Vitals
LCP、INP、CLS 分别观察加载、交互和稳定性。
技术流程图
先用一张图把本期内容串起来。它不是背诵路线，而是排查问题时可以顺着走的证据路线。
mermaid
flowchart TD
s1["本期内容：性能工程把用户等待拆成可定位的链路"]
s2["加载路径：加载性能先看关键资源什么时候到达"]
s3["渲染路径：渲染性能受样式、布局、绘制和合成影响"]
s4["交互响应：交互卡顿常常来自主线程 Long Task"]
s5["核心指标：Core Web Vitals 用用户视角衡量关键体验"]
s6["优化证据：性能优化要先量测，再定位，再验证"]
s7["整体总结：性能工程是从证据出发改善真实体验"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
s6 --> s7
s7 --> check{"能否解释当前页面现象？"}
check -->|能| action["记录证据并进入下一步"]
check -.->|不能| back["回到上一层重新定位"]
back -.-> s1深入展开
1. 性能工程把用户等待拆成可定位的链路
这一期看 Web 性能工程。我们会讲加载路径怎样从 DNS、网络和资源开始，渲染路径怎样受到 CSS、JavaScript 和图片影响，交互为什么会被 Long Task 卡住，Core Web Vitals 里的 LCP、INP、CLS 分别观察什么，以及优化时怎样用证据定位瓶颈。
这里可以多看一层：先找输入，再看处理过程，最后确认输出。前端很多问题之所以绕，是因为现象出现在页面上，原因却可能藏在网络、样式计算、运行时或构建结果里。
mermaid
flowchart LR
v1["加载：网络和资源"]
v2["渲染：布局和绘制"]
v3["交互：主线程响应"]
v4["指标：体验证据"]
v1 --> v2
v2 --> v3
v3 --> v4排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
2. 加载性能先看关键资源什么时候到达
Network Waterfall 能看到 HTML、CSS、JavaScript、图片和字体的请求顺序。阻塞渲染的 CSS、过大的 bundle、没有命中缓存的图片，都会影响首屏。优化加载时，先问哪些资源是关键路径，哪些可以延后、压缩、缓存或预加载。
把这段机制放到工程里看，最实用的切口是证据。不要急着猜是哪一行代码错了，先确认浏览器或工具实际拿到了什么、计算了什么、丢出了什么结果。
mermaid
flowchart LR
v1["HTML：发现资源"]
v2["CSS：影响渲染"]
v3["JS：下载执行"]
v4["image：影响内容可见"]
v1 --> v2
v2 --> v3
v3 --> v4排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
3. 渲染性能受样式、布局、绘制和合成影响
浏览器要计算样式、布局、绘制和合成。频繁读取布局再写样式，可能触发布局抖动。大面积阴影、滤镜和复杂动画也会增加绘制成本。性能优化不是永远少写 CSS，而是理解哪些变化会影响布局，哪些可以交给合成层更平滑地处理。
这个点在真实项目里常常不是孤立问题。它会和状态、缓存、布局、依赖或团队约束连在一起，所以博客版更强调边界：什么归它管，什么应该交给下一层机制判断。
| 维度 | 含义 |
|---|---|
| style | 计算样式。 |
| layout | 计算位置尺寸。 |
| paint | 绘制像素。 |
排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
4. 交互卡顿常常来自主线程 Long Task
JavaScript 执行、样式布局和渲染调度都要占用主线程。一个很长的任务会阻塞输入响应，让用户感觉卡顿。拆分长任务、减少同步计算、延迟非关键逻辑、使用 Web Worker，都是降低交互阻塞的常见方向。
如果要把它讲给别人听，可以按“现象—证据—机制—边界”的顺序。先让对方看到问题，再解释浏览器或工具为什么会给出这样的结果。
mermaid
flowchart LR
v1["click：用户输入"]
v2["main thread：被长任务占用"]
v3["delay：响应变慢"]
v4["split：拆分和延后"]
v1 --> v2
v2 --> v3
v3 --> v4排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
5. Core Web Vitals 用用户视角衡量关键体验
LCP 关注主要内容什么时候显示出来，INP 关注交互响应是否及时，CLS 关注页面是否发生意外布局移动。它们分别对应加载、交互和稳定性。一个页面可能 LCP 很好但 INP 很差，也可能视觉稳定性差到让用户误点。
这里可以多看一层：先找输入，再看处理过程，最后确认输出。前端很多问题之所以绕，是因为现象出现在页面上，原因却可能藏在网络、样式计算、运行时或构建结果里。
| 维度 | 含义 |
|---|---|
| LCP | 主要内容出现。 |
| INP | 交互响应。 |
| CLS | 布局稳定。 |
排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
6. 性能优化要先量测，再定位，再验证
可以用 Lighthouse、Performance 面板、真实用户监控和构建分析报告一起看问题。实验室数据方便复现，真实用户数据能看到设备、网络和地区差异。优化后要回到同一指标验证，不要只凭感觉说页面更快。
把这段机制放到工程里看，最实用的切口是证据。不要急着猜是哪一行代码错了，先确认浏览器或工具实际拿到了什么、计算了什么、丢出了什么结果。
mermaid
flowchart LR
v1["measure：量测指标"]
v2["diagnose：定位瓶颈"]
v3["change：做优化"]
v4["verify：复测确认"]
v1 --> v2
v2 --> v3
v3 --> v4排查时可以顺着这条线问：当前现象是输入不对、处理过程不对，还是最终结果不对。只要能把问题归到其中一格，后面的工具选择就会轻很多。
常见误区与边界
- 不要把性能简化为 Lighthouse 分数。
- 不要提出没有验证闭环的优化。
- 这一篇不展开：具体性能平台接入。
- 这一篇不展开：极限微优化。
- 这一篇不展开：浏览器内核实现源码。
排查和验证清单
- 先确认问题发生在哪一层：页面结构、样式计算、JavaScript 运行、网络请求、构建产物还是线上交付。
- 用浏览器或工具拿到证据，不只凭肉眼判断。能截图、能看到日志、能看到请求和产物，结论才稳。
- 把最小例子缩到只剩一个变量。变量越少，越容易看清机制。
- 记录输入、处理过程和输出。前端问题往往不是“某个 API 错了”，而是链路中某一步的假设不成立。
- 如果准备把结论放到项目里，再补一层测试、类型检查、可访问性或性能验证。
动手练习
- 用一个最小 HTML 页面复现 Web 性能工程 里的核心现象。
- 打开 DevTools，分别记录结构、样式、控制台、网络或性能面板里的一个证据点。
- 改一个变量，再观察结果是否符合这篇文章里的流程图；如果不符合，把差异写下来。
参考来源与本系列依据
- Web.dev：Core Web Vitals：指标定义
- 浏览器工具：Chrome DevTools Performance：定位证据
- 工程实践：RUM / bundle analysis：真实用户与构建证据
总结
Web 性能工程的核心不是背技巧，而是用证据找到等待发生在哪里，再验证优化是否真的改善体验。
博客版到这里就把视频主线扩成了可复习的技术笔记：先知道它在链路里的位置，再知道它怎么运行，最后知道遇到问题该从哪里查。