从重排到合成：用Performance面板定位真实渲染瓶颈的步骤

性能优化里最常见的误判，是看到页面掉帧就断言“重排太多”，然后开始给元素加 `transform`、`will-change`，甚至把整块 DOM 藏起来。结果有时帧率确实上去了，有时却毫无变化。原因在于，浏览器渲染并不是单一动作，而是一条流水线：样式计算、布局（重排）、绘制、合成。任何一个环节都可能成为瓶颈，而 Performance 面板的价值，正是把这条流水线拆开，让你看到真实耗时发生在哪里。

下面这套步骤，不追求“看一眼就懂”，而是帮你建立一条可复现的证据链：从录制、找坏帧，到区分主线程与合成线程，最后定位到具体代码或图层。

第一步：先定义场景和指标，别急着点录制

录制之前，先回答三个问题：你要优化的是滚动、动画、输入响应，还是首屏渲染？卡顿发生在哪个交互之后？可接受的指标是什么，是稳定 60fps，还是输入延迟低于 100ms？只有场景固定，trace 才有可比性。

环境也要控制：用无痕窗口排除扩展干扰，开启 CPU 降速（4x 或 6x）模拟中低端设备，勾选 Screenshots 和 Memory。录制时间不要太长，3 到 5 秒足够，关键是完整覆盖一次卡顿操作。

第二步：在 Frames 轨道找“坏帧”

录完后先看顶部的 Frames 轨道。绿色条代表帧，红色或带斜纹的条通常意味着掉帧。选中一帧，看它的总耗时和主要组成。这里先不要陷进细节，只判断一件事：这一帧是主线程忙，还是主线程空闲但画面依然没刷新？

如果是主线程长任务导致，继续看 Main 火焰图；如果主线程很轻，甚至有空闲，但 Frames 仍然掉，瓶颈可能在合成器、栅格化或 GPU。这个判断能帮你少走很多弯路。

第三步：顺着 Main 火焰图辨认渲染阶段

展开 Main 轨道，重点找这些事件：`Recalculate Style`、`Layout`、`Update Layer Tree`、`Paint`、`Composite Layers`。它们对应渲染流水线的不同阶段。

- `Recalculate Style` 耗时高：可能是选择器复杂、样式表过大，或大量元素类名切换。
- `Layout` 耗时高：布局范围大、频繁读写几何属性，或触发了强制同步布局。
- `Paint` 耗时高：大面积重绘、阴影、滤镜、圆角、渐变等绘制成本高的区域被频繁更新。
- `Composite Layers` 或 `Rasterize` 耗时高：问题可能不在 JS，而在图层数量和栅格化压力。

注意看 Self Time，而不是只看总时间。一个父事件很长，不代表它自己有问题，可能是子事件拖累。

第四步：用 Bottom-Up 和 Call Tree 追到源码

切到 Bottom-Up 面板，按 Self Time 排序，通常能最快找到“最耗时的那个函数”。再切到 Call Tree，看它的调用栈。典型的重排陷阱是：在循环里先读 `offsetHeight`，再写 `style.height`，再读，再写。浏览器被迫反复布局，这就是强制同步布局。

如果耗时函数来自第三方库，不要停在“库的问题”。继续看它触发了哪些样式变更、影响了多大布局范围，很多第三方组件可以通过隔离容器或改用合成动画来规避。

第五步：用 Rendering 工具验证重排、重绘还是合成

DevTools 的 Rendering 面板是验证假设的好帮手。打开 Paint flashing，可以看到哪些区域在重绘；打开 Layer borders，能看清合成层边界；打开 Layout Shift Regions，能观察布局抖动。如果动画只改 `transform` 和 `opacity`，通常只走合成；如果改 `top`、`left`、`width`、`height`，大概率会触发布局和绘制。

这一步能防止你把“绘制问题”误判成“重排问题”，也能确认合成层是否真的在帮忙。

第六步：检查合成与图层成本

合成不是免费午餐。打开 Layers 面板，看图层数量、尺寸和内存占用。图层过多会带来内存和合成开销；单个图层过大，栅格化成本会很高。频繁使用 `will-change` 或大面积提升图层，可能把主线程压力转移到 GPU，表现为主线程不忙但依然掉帧。此时应减少图层面积、避免滥用滤镜和遮罩，并让动画元素尽量保持小尺寸。

第七步：修复、对比、回归

定位后，一次只改一个变量：比如把动画从 `left` 改为 `transform`，或把读写分离，或缩小重绘区域。然后用同样的场景、同样的 CPU 降速重新录制，对比帧时间、Layout 时长、Paint 时长和长任务数量。Performance Monitor 可以实时观察 CPU、FPS 和 DOM 节点数。把前后 trace 存档，团队讨论时才有共同事实。

真实渲染瓶颈的定位顺序，应该是：先确认哪一类帧出了问题，再判断主线程还是合成线程，最后追到代码或图层。重排只是嫌疑人之一，不是结论。Performance 面板也不是用来看热闹的火焰图，而是把渲染流水线拆成证据链的工具。下一次遇到卡顿，不妨按这条路径走一遍：定义场景、录制、找坏帧、辨认阶段、追到源码、验证合成、对比回归。你会发现，很多所谓“重排问题”，其实另有真凶。