浏览器渲染引擎：重排、重绘与合成层

可视化演示

演示浏览器渲染引擎的核心流程：DOM/CSSOM构建到合成层输出，重排与重绘的触发条件及性能影响，以及合成层提升与will-change优化策略。

渲染流水线：把菜谱变成像素

顾客在“像素馆”点了一份青椒肉丝盖饭。收银机将点菜单（HTML）传给后厨：米饭打底、肉丝铺面、青椒点缀。小美先让助手把菜单拆成“食材台账”（DOM），记录每样食材的种类、顺序和层级；接着调出后厨的“出品规范”（CSS），把酱色、挂汁、脆度等视觉规则整理成“规范表”（CSSOM）。这两本册子，一道菜的结构和外观都有了。

台账只回答“有什么”，规范表只回答“怎么摆”。小美把两本册子合并成一张出餐卡（渲染树），卡片上写明了每样食材最终将以什么样式呈现。之后主厨正式开工：先规划餐盘上每个食材的坐标与尺寸（布局），再逐个绘制上色（绘制），最后把提前备好的装饰层通过传菜电梯叠加到一起（合成）。这一整套动作，就是浏览器渲染引擎把 HTML 和 CSS 变成像素的流水线。

渲染引擎是一条永不休息的流水线：HTML 解析器把 HTML 变成 DOM 树，CSS 解析器把样式表变成 CSSOM 树，两棵树合并为渲染树，再依次经过布局、绘制和合成。整条流水线的目标只有一个——在 16.7 毫秒内完成一帧。一旦超时，用户就会感到卡顿，就像客人等菜等急了。

小美盯着后厨的计时器想：菜出得快不快，不取决于某一个环节神速，而取决于整条流水线每个环节都不超时。多出来的毫秒就像多出来的客诉单，前端性能优化的本质，就是让整条出餐流水线更均衡、更高效，把每一帧都卡进 16.7 毫秒的节拍里。

重排机制：主菜尺寸一变，全桌重新摆

每逢宴会，小美最怕客人说：“主菜再大一点。”她不得不把整桌餐盘重新规划一遍——配菜移到哪里、酱汁碗放在哪儿、装饰小旗换到哪一侧，全部推倒重来。这个动作在浏览器里就叫重排（Reflow），也叫布局（Layout）。

当元素的尺寸、位置、内容发生变化时，浏览器必须重新计算受影响节点的几何属性。最常见的触发原因包括：增删 DOM 节点、修改宽高/边距/边框、文字内容改变、浏览器窗口缩放，以及在 JavaScript 里读取 offsetWidth、scrollHeight 等强制同步布局的属性。每一条都像在宴会上突然喊一句“主菜改尺寸”。

重排的开销和页面规模直接相关：DOM 节点越多，布局计算量越大；如果改动发生在文档顶部，整个页面都可能重新布局，这就是“页面级影响”。于是工程师们总结出一条铁律：能减少重排次数就绝不多触发，必须重排时也要尽量缩小影响范围。

小美的对策是“攒着改”：把所有摆盘调整攒成一张新图纸，一次性告诉后厨。浏览器也一样，把多次样式改动合并成一次批量更新，能省下大量重复的布局计算，这就是“批量改写”的智慧。

重绘机制：只换颜色不动餐桌

还有一种更“轻”的要求：主菜的笋丝要换成青椒丝，但菜量大小、摆放位置一概不变。小美只需重新给这盘菜上色，不用去动整桌的布局。浏览器里的对应动作就是重绘（Repaint），也叫绘制（Paint）。

重绘的触发条件是“视觉属性”的变化——颜色、背景、边框色、阴影、可见性（visibility）、圆角等。浏览器不用重新计算几何，只需要把对应区域重新上一层色。重绘成本与脏区面积有关，范围越大、像素越多，光栅化就越费时，就像给一整面墙刷漆比刷一面小镜子慢得多。

很多人以为重绘比重排便宜就可以随意用，实际上它仍然会占用主线程资源。尤其在大面积背景渐变或阴影的场景下，一次重绘也可能吃掉一帧的预算。重绘虽然不重新摆盘，但刷漆刷得太多，同样会耽误出餐。

小美发现，频繁给同一盘菜上色同样累人。最优解是把“常常变色”的菜装进独立的工作篮里，之后只换篮子，不动主操作台——这就引出了合成层。

合成层优化：独立工作台带来的加速度

为了减少重复摆盘，小美在后厨设置了几个“备用工作台”：甜点、酱汁、小料先在各自的台面上备好，上菜时由传菜电梯（合成器）叠加到主餐盘上。这些小台面互不干扰，动画只需移动台面，无需重摆主餐盘。浏览器中的“合成层”正是这样的备用工作台。

现代浏览器会把页面拆分成多个图层。每个图层都有自己的位图，合成器在 GPU 上把多个图层合并成最终画面。如果动画只改变 transform 或 opacity，元素在自己的合成层里平移、淡入淡出，既不会触发重排也不会触发重绘，成本几乎只剩合成。这是性能优化中最关键的手段。

will-change: transform 就是告诉浏览器“这个元素接下来会动”，让它提前创建好合成层。但它不能滥用：每个图层都占用内存与 GPU 资源，图层过多会造成“层爆炸”，反而拖累性能。备用工作台备得太多，后厨连走路的地方都没有了。

小美的经验是：动画尽量用位移和透明度，而不是 width、height、top、left。前者是“换台面”，后者是“重摆整个桌面”——前者便宜得多，后者贵得让人心疼。

性能监控：给后厨装一个计时摄像头

小美以前靠感觉判断后厨是否忙乱，现在她给每个工位装了计时摄像头。Chrome DevTools 里的 Performance 面板就是这样的摄像头——录制一段操作，就能看到每一帧里脚本、样式、布局、绘制、合成各占了多长时间。

帧时间线（Frame Timeline）把 16.7 毫秒的预算画成一根根彩条；主线程任务超过预算时，彩条会标红。FPS 是另一个关键指标：稳定在 60 说明单帧没有超预算，掉到 30 以下说明某一帧做了太多事。就像后厨一秒只能出 30 道菜，客人自然会觉得“慢”。

Rendering 面板还能做高亮重排和重绘区域，并查看合成层的边界，帮工程师定位“是哪一块代码在偷偷重排”。数据是不会说谎的：优化永远应该从测量开始，而不是从猜测开始。

小美用摄像头拍到最耗时的一幕：原来切菜工位来回走动，导致整个流水线频繁停摆。找到真凶后，她开始着手改造流程——前端优化也一样，先定位，再动手。

工程实践：让出餐流水线不再抖动

小美发现一个隐蔽的耗时怪癖：有些厨工切一刀看一下图，挪一勺又看一下图——每看一眼都让后厨重新摆一次桌。JavaScript 里的“布局抖动”（Layout Thrashing）正是如此：循环中先读 offsetHeight，再改样式，下一次循环又去读——每次读取都强制浏览器立刻重新布局。

解决布局抖动的第一原则是“读写分离”：把所有的读操作集中在一起，把写操作集中在一起，避免互相打断。第二原则是批量更新：用类名一次性套用多个样式，或借助 DocumentFragment 批量插入节点，让浏览器只做一次布局。小美的后厨也改成了“先记录再执行”：所有请求先写在备忘板上，最后统一开工。

在框架层面，React 的批处理和 Vue 的 nextTick 都是为了“攒一批更新再渲染”，这就是组件级刷新。页面数据特别多时，还应使用长列表虚拟化（虚拟滚动），只渲染视口附近的节点，极大减少 DOM 规模——相当于只把客人看得见的菜端上桌，后厨不会再囤积一冰箱用不上的备料。

小美最终把后厨改造成“先记录再执行”的方式：所有请求先记在备忘板上，最后统一开工。高峰期不仅没掉链子，反而每道菜都稳稳地按时上桌。这就是工程优化的意义——不是更快地做事，而是不再重复做事。

AI 应用场景

Python 演示

import time class LayoutSimulator:    def __init__(self, node_count=3000):        self.nodes = node_count        self.layout_cache = None     def write_style(self):        self.layout_cache = None     def read_geometry(self):        if self.layout_cache is None:            time.sleep(self.nodes * 1e-6)            self.layout_cache = True        return self.layout_cache def run_batch(n=50):    sim = LayoutSimulator()    start = time.perf_counter()    for _ in range(n):        sim.write_style()    for _ in range(n):        sim.read_geometry()    return time.perf_counter() - start def run_thrash(n=50):    sim = LayoutSimulator()    start = time.perf_counter()    for _ in range(n):        sim.write_style()        sim.read_geometry()    return time.perf_counter() - start if __name__ == '__main__':    batch = run_batch()    thrash = run_thrash()    print('批量更新耗时: %.4f 秒' % batch)    print('布局抖动耗时: %.4f 秒' % thrash)    print('抖动是批量的 %.1f 倍' % (thrash / batch))

1. self.layout_cache = None每次修改样式都让之前的布局结果失效，模拟浏览器标记布局脏。
2. if self.layout_cache is None:布局缓存失效时才重新计算，和浏览器“读取几何属性时强制同步布局”一致。
3. time.sleep(self.nodes * 1e-6)模拟重排耗时，耗时与节点数量成正比。
4. run_batch(n=50)先全部写、再一次读，只触发一次强制布局，模拟批量更新。
5. run_thrash(n=50)写后立即读，每次读取都强制同步布局，模拟布局抖动。
6. print('抖动是批量的 %.1f 倍' % (thrash / batch))用时间比直观展示抖动带来的性能损失。

常见误区

面试题