1.1 解析与 DOM/CSSOM 构建 (Parsing)#

浏览器首先解析 HTML 字符串，构建 DOM 树（Document Object Model）。与此同时，解析 CSS 文件或 style 标签，构建 CSSOM 树（CSS Object Model）。这两个过程是并行的，但 DOM 的构建可能会被同步执行的 JavaScript 阻塞。

1.2 样式计算 (Style Calculation)#

渲染引擎将 DOM 树和 CSSOM 树合并，计算出每个 DOM 节点的最终样式。这一步需要处理选择器匹配、层叠规则（Cascading）以及继承逻辑。最终生成的结果是 Render Tree（渲染树），它只包含需要显示的节点（例如 display: none 的节点会被剔除）。

1.3 布局 (Layout / Reflow)#

布局阶段的任务是计算渲染树中每个节点的几何信息：位置（x, y）和尺寸（width, height）。浏览器从根节点开始遍历，根据盒模型规则确定每个元素在视口内的确切坐标。

1.4 绘制 (Paint)#

绘制阶段并非直接输出像素，而是生成一系列绘制指令（如“在坐标 (10, 10) 处画一个半径为 5 的圆”）。浏览器会将页面拆分为多个图层（Layers），并为每个图层生成各自的指令列表。

1.5 合成 (Composite)#

这是现代浏览器性能优化的关键。合成线程（Compositor Thread）将页面拆分成的图层发送给 GPU。GPU 根据这些图层及其属性（如位移、透明度），将它们“拼”在一起显示在屏幕上。

flowchart TD
    HTML["HTML"] --> DOM["DOM Tree"]
    CSS["CSS"] --> CSSOM["CSSOM Tree"]
    DOM --> RenderTree["Render Tree"]
    CSSOM --> RenderTree
    RenderTree --> Layout["Layout (几何计算)"]
    Layout --> Paint["Paint (绘制指令)"]
    Paint --> Layerize["Layerize (分层)"]
    Layerize --> Composite["Composite (GPU 合成)"]
    
    subgraph MainThread ["主线程 (Main Thread)"]
        DOM
        CSSOM
        RenderTree
        Layout
        Paint
    end
    
    subgraph GPU ["GPU 进程"]
        Composite
    end

3.1 合成层 (Compositing Layers)#

当一个元素被提升为“合成层”时，它拥有独立的图形上下文。在动画过程中，如果只改变该层的合成属性（如 transform 或 opacity），浏览器只需要在合成线程中通知 GPU 重新组合这些层，而无需重新布局或重新绘制。

3.2 触发合成层提升的条件#

以下属性会触发浏览器为元素创建独立的合成层：

1. 使用 3D 变换：transform: translateZ(0), rotate3d() 等。
2. 使用 will-change 属性：显式告知浏览器该元素即将发生变化。
3. 对 opacity, transform, filter, backdrop-filter 应用 transition 或 animation。
4. <video>, <canvas>, <iframe> 元素。

3.3 为什么 Transform 和 Opacity 如此高效？#

与其他属性不同，transform 和 opacity 的处理完全发生在合成线程和 GPU 中。

• Transform：GPU 只需要对已有的纹理（Texture）进行矩阵变换（Matrix Transform），这在硬件层面是极快的。
• Opacity：GPU 只需要在合成时调整图层的 Alpha 通道。

1
/* 低效方案：触发回流 */
2
.box-slow {
3
  position: absolute;
4
  left: 0;
5
  transition: left 0.3s ease;
6
}
7
.box-slow:hover {
8
  left: 100px;
9
}
10

11
/* 高效方案：仅触发 Composite */
12
.box-fast {
13
  transform: translateX(0);
14
  transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1);
15
  /* 提前提升为合成层，避免动态提升带来的闪烁 */
16
  will-change: transform;
17
}
18
.box-fast:hover {
19
  transform: translateX(100px);
20
}

5.1 隐式合成 (Implicit Compositing) 的陷阱#

当浏览器决定渲染层级时，有一个严格的规则：如果元素 B 的 z-index 高于元素 A，且 A 是一个独立的 GPU 合成层，那么为了保证 B 依然能盖在 A 上面，浏览器会被迫把 B 也提升为一个独立的 GPU 合成层。

设想一个常见的业务场景： 你给页面底部的一个绝对定位的背景动画加了 will-change: transform（创建了层 A）。 在这个背景之上，有 1000 个普通的商品列表节点（属于层 B）。 因为这 1000 个节点在 z 轴上高于背景层 A，浏览器不得不为这 1000 个节点创建 1000 个独立的 GPU 纹理！

后果：

• 极高的 GPU 显存占用（手机端极易引发 OOM 闪退）。
• 每次滚动时，合成线程需要处理成百上千个图层的计算，掉帧严重。

5.2 如何排查图层爆炸？#

千万不要盲目猜测。在 Chrome DevTools 中，按下 Cmd + Shift + P (Mac) / Ctrl + Shift + P (Win)，搜索并打开 “Show Layers” 面板。 这里会 3D 可视化地展示当前页面的所有 GPU 图层。点击任意图层，右侧的 Details 会明确告诉你它被提升为合成层的原因（例如：Compositing reason: Assumed to overlap a layer with a composited animation —— 这就是典型的隐式合成受害者）。

解决方案：给那个需要硬件加速的底层元素设置一个极高的 z-index（如果视觉上允许），或者将其与其他正常文档流的元素在空间上剥离开来。