2、浏览器渲染管线：CPU与GPU分工、渲染管线（JS→Style→Layout→Paint→Composite）、帧预算概念
好，咱们今天聊点硬核的。
浏览器渲染管线，说白了就是浏览器把代码变成像素的流水线。我当年刚入行时，觉得写个页面能跑就行，管它怎么渲染的。直到有一次，一个简单的滚动动画卡成PPT，我才意识到——不懂渲染管线，你连问题出在哪都不知道。
2.1 CPU与GPU的分工
先搞清楚谁干什么活。
CPU（中央处理器）：擅长处理复杂逻辑、分支判断、串行任务。它负责解析HTML、执行JavaScript、计算样式、生成布局树。说白了，所有「动脑子」的活都归CPU。
GPU（图形处理器）：擅长并行计算、批量处理像素。它负责把CPU算好的东西画到屏幕上。纹理合成、位图绘制、图层合成，这些重复性高、数据量大的活，交给GPU最合适。
我个人的习惯是：能用GPU干的活，别让CPU干。比如动画，能用CSS transform就别用JS改left/top。为什么？因为transform的合成是在GPU上完成的，不触发重排重绘。
核心分工总结
| 组件 | 负责阶段 | 特点 |
|---|---|---|
| CPU | JS → Style → Layout | 串行、复杂逻辑、分支判断 |
| GPU | Paint → Composite | 并行、批量像素处理、纹理操作 |
2.2 渲染管线的五个阶段
浏览器渲染一个页面，大致走五步。每一步都可能成为性能瓶颈。
阶段一：JavaScript（JS）
你写的JS代码在这里执行。DOM操作、样式修改、事件绑定，全在这。我见过最离谱的项目，一个滚动事件里绑了三个重排操作——页面直接卡死。
避坑指南：JS里尽量减少DOM查询和修改的交替。比如先读完所有需要的数据，再一次性修改DOM。我曾经在一个数据大屏项目里，把循环里的getElementById提到循环外面，帧率从20fps直接跳到55fps。
阶段二：Style（样式计算）
浏览器根据CSS选择器，计算出每个元素最终应用的样式。这里有个坑：选择器越复杂，计算越慢。比如 .nav ul li a 这种四级选择器，比 .nav-link 慢得多。
我个人建议：尽量用类选择器，少用后代选择器。尤其是大型项目，样式计算的时间会随着选择器复杂度指数级增长。
阶段三：Layout（布局/重排）
这是最耗性能的阶段之一。浏览器要计算每个元素的位置和大小。你想想看，一个页面几百个元素，每个都要算宽高、边距、位置——CPU得忙活好一阵。
什么操作会触发Layout？
- 改变元素的宽高、边距、定位
- 读取
offsetHeight、clientWidth等属性 - 添加或删除DOM元素
嗯，这里要注意：读取某些属性会强制触发Layout。比如你在修改样式后立即读取 offsetHeight，浏览器为了给你准确的值，只能先重新布局。这叫「强制同步布局」，能避免就避免。
阶段四：Paint（绘制）
布局算完了，浏览器开始画像素。文字、颜色、阴影、边框，全在这里生成位图。Paint本身不慢，但如果你有大量复杂的绘制操作——比如大面积的渐变、阴影、圆角——GPU也得喘口气。
我曾经优化过一个地图项目，发现卡顿的原因是每个标记都用了 box-shadow 和 border-radius。改成纯色背景加简单边框后，绘制时间直接减半。
阶段五：Composite（合成）
最后一步。浏览器把各个图层合成到一起，输出到屏幕。这一步在GPU上完成，通常很快。但如果你有太多图层，或者图层频繁变化，合成也会成为瓶颈。
避坑指南：用 will-change 属性告诉浏览器哪些元素会变化。比如 will-change: transform，浏览器会提前为这个元素创建独立图层，避免影响其他元素。但别滥用——图层太多，GPU内存会爆。
小技巧：在Chrome DevTools的Performance面板里，可以清楚看到每个阶段耗时。我每次做性能优化，第一件事就是打开它，看看瓶颈在哪。
2.3 帧预算概念
帧预算，说白了就是每一帧你只有16.67毫秒。
为什么是16.67ms？因为屏幕通常60Hz刷新，每秒60帧，每帧约16.67ms。如果浏览器处理一帧超过这个时间，下一帧就会延迟，用户就会感觉到卡顿。
我个人的经验是：别把16.67ms全用完。留出3-5ms的余量，应对突发情况。比如用户突然滚动、点击，或者后台有定时器触发。实际可用预算大概在10-12ms左右。
帧预算分配建议
| 阶段 | 建议耗时 | 说明 |
|---|---|---|
| JS执行 | ≤ 4ms | 避免长时间同步计算 |
| Style + Layout | ≤ 3ms | 减少DOM操作和样式变更 |
| Paint | ≤ 3ms | 简化绘制内容 |
| Composite | ≤ 2ms | 控制图层数量 |
| 余量 | ~4ms | 应对突发情况 |
你想想看，如果JS执行花了8ms，那留给后面三个阶段的时间就只剩8ms了。一旦Layout再卡一下，整帧就超了。所以性能优化的本质，就是给每个阶段「抢时间」。
注意：帧预算不是死的。如果页面是60fps，预算就是16.67ms。如果是120Hz屏幕，预算只有8.33ms。移动端低端设备可能只有30fps，预算33ms。所以永远以目标设备的帧率为准。
2.4 实战建议
说了这么多，落地到实际开发，我总结几条铁律：
- 能用CSS就别用JS。动画用transform + opacity，别用left/top。
- 减少强制同步布局。读写分离，先读完再写。
- 控制图层数量。will-change别滥用，每个图层都占GPU内存。
- 监控帧预算。用Performance面板看每帧耗时，超过16ms就要警惕。
- 优先优化Layout和Paint。这两个阶段最耗性能，也最容易优化。
我记得有一次帮一个电商团队优化首页，他们首页有十几个轮播图，每个都用JS控制位移。我改成CSS transform后，首页加载速度没变，但滚动流畅度从30fps直接到60fps。用户反馈说「页面终于不抖了」。
嗯，这就是理解渲染管线的价值。
一句话总结：渲染管线就是浏览器的「流水线作业」，每个工位都有时间限制。你作为工程师，就是那个「掐表的人」——哪个工位超时了，就去优化哪个工位。