使用 DevTools 调试卡顿的 CSS 动画

CSS 动画卡顿源于帧预算超支：在 60fps 下，浏览器每帧的处理时间约为 16.7ms，任何因布局重算、绘制或主线程繁忙而导致的超时帧都会拉低帧率，并以明显的卡顿形式呈现。解决方案绝非”多加几个 will-change”，而是诊断：找出渲染管线的哪个阶段超时，以及发生在哪个线程上。本文将介绍一套基于当前版本 Chrome DevTools 的系统化四面板工作流——Rendering（渲染）、Performance（性能）、Animations（动画）和 Layers（图层）——帮助你追溯动画卡顿的根本原因，并提供一个可复现的前后对比示例。

本文面向已了解 transform 和 opacity 开销较低、但缺乏系统排查流程的读者。在笔记本上运行流畅、在中端 Android 设备上却出现卡顿的动画，是最典型的场景。你需要的是一套分诊方法，而不是又一条属性使用建议。

什么是动画卡顿？

卡顿是指用户能够感知到的丢帧或延迟帧。要维持 60fps，浏览器必须在约 16.7ms（1000ms ÷ 60）内完成每一帧的渲染，这个时间窗口涵盖该帧的样式重算、布局、绘制和合成。一旦某帧超时，浏览器就会错过截止时间，实际帧率随之下降——降至 30fps 甚至更低——动画看起来便会出现跳帧。Google 的渲染性能指南对此有相同的阐述：流畅的视觉变化需要在每帧时间窗口内完成，而动画是帧预算最容易被突破的地方，因为人眼正在追踪连续的运动。

为什么一帧的延迟就能被察觉，而一次缓慢的网络请求却不会？原因在于：动画是一系列帧，大脑将其整合为连续运动。一帧的延迟就会打破这种整合，运动中途的停顿会被感知为跳跃。这正是”基本流畅”远远不够的原因——决定感知质量的是最差的那一帧，而非平均水平。

渲染管线简介

每次视觉更新都经历一条固定的管线：解析 → 样式 → 布局 → 绘制 → 合成。浏览器将 HTML 和 CSS 解析为 DOM 和 CSSOM，计算应用于各元素的样式（样式），计算每个盒子的几何形状和位置（布局），将像素光栅化到图层中（绘制），最后将各图层合并为最终显示的画面（合成）。web.dev 渲染管线详解是权威的深度参考资料；这里只需了解其简要版本即可。

本文其余内容的核心论点是：管线的每个阶段都运行在特定线程上，并体现在特定的 DevTools 面板中。布局和绘制运行在主线程上，与 JavaScript 共享该线程。合成则在独立线程上运行。仅涉及合成的动画——移动现有图层、改变其透明度——几乎完全绕过了主线程。而触发布局的动画则会在每一帧将工作拉回主线程，与其他所有任务竞争资源。下文介绍的各个面板，正是让你看清这一区别的工具。

哪些 DevTools 面板可以诊断动画卡顿？

系统化的卡顿诊断按顺序使用四个面板：Rendering 面板用于快速目视检查（绘制闪烁是否出现在不该出现的地方？），Performance 面板用于录制并定位慢帧的根本原因，Animations 面板用于隔离造成问题的关键帧或属性，Layers 面板用于评估合成器图层提升是否有帮助，或是否带来了内存压力。按此顺序使用：Rendering 能在数秒内快速排除整类问题，Performance 提供完整的追踪记录，Animations 将问题缩小到具体属性，Layers 则验证修复方案的代价。

Rendering 面板：快速检查

Rendering 面板是你的第一站，因为它能直观、即时地回答一个问题：你的动画是否在不该重绘时触发了重绘。通过命令菜单（Cmd/Ctrl+Shift+P，输入”Show Rendering”）或 More Tools → Rendering 打开它（Chrome DevTools 渲染参考）。有三个开关值得关注：

• Frame Rendering Stats：在动画运行时显示实时 FPS 读数和 GPU 内存叠加层。动画期间数值明显低于 60，即可确认卡顿存在。
• Paint flashing：通过绿色闪烁高亮浏览器重绘的区域。仅对 transform 进行动画处理的元素在移动时不应产生绿色闪烁；若绿色闪烁跟随动画出现，说明正在触发绘制。
• Layer borders：用橙色边框标出合成器图层。用它确认你期望硬件加速的元素是否真的获得了独立图层，同时发现非预期的图层。

操作步骤：

1. 打开 Rendering 面板。
2. 启用 Paint flashing 并触发动画。
3. 如果动画元素在运动时出现绿色闪烁，说明动画每帧都在触发绘制——某个布局或绘制属性正在被动画化。这表明存在属性层面的问题，需要进一步打开 Performance 面板排查。
4. 如果没有闪烁但运动仍然卡顿，瓶颈很可能是主线程 JavaScript，而非绘制——同样需要用 Performance 面板来排查。

Performance 面板：定位慢帧根因

Performance 面板用于录制动画，并精确读取管线的哪个阶段超出了帧预算。它展示 FPS 图表、Frames 轨道中的逐帧耗时、主线程活动，以及当前版本 Chrome 中的 Insights 侧边栏（可自动标记强制回流等问题）（Chrome DevTools 性能参考）。

录制前，请先对 CPU 进行降速，以模拟实际出现卡顿的设备环境。Chrome DevTools 在 Capture settings 中提供了 CPU 降速预设，面板提供”4x slowdown”选项，推荐使用能近似低性能硬件的降速倍数（性能参考，CPU 降速）。降速之所以重要，是因为 CSS 动画在本地性能分析中通过、在生产环境卡顿的最常见原因，正是设备差异：一台同时开着多个标签页的中端 Android 设备，其 CPU 预算只有开发笔记本的一小部分。降速能近似模拟这种差距，但无法完全复现内存压力和并发 GPU 负载的影响。

操作步骤：

1. 打开 Performance 面板，勾选 Screenshots。
2. 在 Capture settings（齿轮图标）中设置 CPU 降速预设。
3. 点击 Record，运行动画几秒后点击 Stop。
4. 首先查看 FPS/Frames 轨道。帧上方的红色标记表示该帧超出了预算。
5. 放大一个问题帧，扫描 Main 轨道。

以下是动画调试中最实用的一条启发式规则：

Main 轨道中黄色条下方的紫色条 = 强制同步布局。红色三角形是跳转到修复点的快捷入口。

在主线程轨道中，紧跟在黄色 JavaScript 条下方出现的紫色 Recalculate Style 或 Layout 条，表明发生了强制同步布局——JavaScript 在写入 DOM 后立即读取了布局属性，迫使浏览器在脚本执行过程中同步解析几何信息。在样式写入后读取 offsetWidth、offsetTop 或调用 getBoundingClientRect()，都会强制浏览器同步刷新布局；Paul Irish 的经典强制布局/回流触发列表枚举了所有触发条件。紫色条上的红色三角形会打开一个 Summary 条目，其中包含”Layout Forced”警告以及指向对应 JS 代码行的源文件链接。web.dev 的布局抖动指南深入讲解了读写交错的模式。

当黄色条下方没有紫色条时，说明 JavaScript 完成了自己的工作，并让浏览器按自己的节奏完成渲染——这正是你希望看到的追踪结果。

Animations 面板：隔离问题关键帧

Animations 面板允许你检查、拖拽和减速正在运行的动画，从而将卡顿定位到特定的关键帧或属性，而非整个动画。通过 More Tools → Animations 打开它（Chrome DevTools 动画文档）。Chrome 会监听动画并在其触发时列出，你可以检查捕获的动画、拖拽其时间轴，并查看其关键帧。

它的诊断价值来自与 Paint flashing 的结合使用。将动画减速至 10% 播放速度，同时在 Rendering 面板中观察 Paint flashing，是识别哪个关键帧触发重绘的最快方式——绿色闪烁会在问题属性值生效的精确时刻出现。

操作步骤：

1. 打开 Animations 面板并触发动画，使其出现在列表中。
2. 将播放速度设置为 10%（控制项位于面板顶部）。
3. 在启用 Paint flashing 的情况下，拖拽时间轴并观察绿色闪烁。
4. 如果绿色闪烁出现在时间轴的某个特定位置，则将排查重点集中在该时刻处于激活状态的关键帧上。

Firefox 和其他浏览器也提供各自的动画检查器；本文以 Chrome 为主要参考。

Layers 面板：评估合成器开销

Layers 面板展示哪些元素被提升为独立的合成器图层、提升原因，以及对应的内存开销——这正是避免随意添加 will-change 的依据。通过 More Tools → Layers 打开它（Chrome DevTools 图层文档）。选中某个图层后，详情面板会显示其内存占用和合成原因。

图层提升是一种权衡。将元素移至独立图层，合成器在对其进行动画处理时无需重绘相邻元素，但每个图层都会为其纹理分配 GPU 内存。MDN 的 will-change 文档明确指出，该属性是最后手段：将其应用于过多元素会浪费资源，因为浏览器本身已经对开销较低的属性进行了优化，过度提升反而会降低性能。使用 Layers 面板统计已提升的图层数量，并确认每个图层的内存占用是否物有所值。

前后对比实例：left 与 transform 的动画对比

对 left 进行动画处理会在每一帧触发布局；而对 transform: translateX() 进行动画处理则既不触发布局，也不触发绘制。相同的运动效果运行在不同的线程上。以下是有问题的版本，对 left 进行动画处理：

/* 有问题：对布局属性进行动画处理 */
.box {
  position: absolute;
  left: 0;
  width: 100px;
  height: 100px;
  background: tomato;
  animation: slide 1s ease-in-out infinite alternate;
}

@keyframes slide {
  to {
    left: 200px;
  }
}

各面板在此版本下的表现：Rendering 面板在整个动画过程中持续对该盒子进行绿色闪烁，因为改变 left 会强制触发布局，而布局之后必然伴随绘制。Performance 面板的 Main 轨道在每一帧都充满紫色的 Recalculate Style 和 Layout 条，启用 CPU 降速后，Frames 轨道也会显示超出预算的帧。left、top、width 和 height 都会触发布局——各属性的详细说明参见 CSS Triggers——而布局运行在主线程上，因此会与其他所有任务竞争 16.7ms 的帧预算。

以下是使用 transform 重写后的版本，实现相同的运动效果：

/* 修复版：对仅合成属性进行动画处理 */
.box {
  position: absolute;
  left: 0;
  width: 100px;
  height: 100px;
  background: tomato;
  animation: slide 1s ease-in-out infinite alternate;
}

@keyframes slide {
  to {
    transform: translateX(200px);
  }
}

translateX 通过 transform 实现相同的位移效果。重写后：Paint flashing 在运动期间不再出现绿色闪烁，Performance 面板的 Main 轨道不再在每帧填满紫色条，动画在合成器线程上运行。合成器可以在不触发布局或绘制的情况下对 transform 和 opacity 进行动画处理，因此浏览器只需移动现有的图层纹理，而无需在每帧重新计算几何信息。

修复清单

修复方法就是属性替换：将所有触发布局或绘制的属性替换为 transform 或 opacity。下表将各动画意图映射到对应的仅合成属性。

最安全且兼容性最广的可动画 CSS 属性是 transform（平移、缩放、旋转、倾斜）和 opacity，因为浏览器通常可以在不触发布局或绘制的情况下在合成器上运行它们。filter 对于 blur() 等函数也可以进行 GPU 加速，但支持情况和行为因浏览器而异，因此在假设其”免费”之前，请先在 Rendering 面板中通过 Paint flashing 加以验证——MDN 的 filter 文档描述了该属性，CSS Triggers 记录了各引擎下其渲染影响。许多其他可动画属性会触发绘制，而改变尺寸或位置的属性通常会在主线程上触发布局重算。

对于 JavaScript 驱动的动画，应将所有 DOM 读取操作集中在所有 DOM 写入操作之前。上述实例追踪中的强制同步布局，正是由于在写入后读取布局属性引起的；将读取操作统一放在前面，浏览器就能从上一帧的布局结果中直接获取数据，而无需同步刷新新的布局。布局抖动指南详细介绍了这一模式。

应有策略地使用 will-change，而非默认添加。在即将对某个元素进行动画处理时添加它，动画结束后将其移除；根据 MDN 的说明，大范围应用会浪费 GPU 内存，因为浏览器本身已经对开销较低的属性进行了优化。请在 Layers 面板中确认其实际效果。

滚动驱动动画：不同的卡顿特征

使用 animation-timeline: scroll() 或 animation-timeline: view() 声明的滚动驱动动画，改变了你在 DevTools 中的排查方向。当它们仅对 transform 或 opacity 进行动画处理时，运行于合成器线程，因此其卡顿不会在 Main 轨道中以长任务的形式出现——应转而查看 Frames 轨道中的丢帧情况。MDN 的 animation-timeline 文档和 Chrome 滚动驱动动画指南介绍了该特性及其浏览器支持基线。如果你应用了 Main 轨道的排查方法却一无所获，但 Frames 轨道仍显示超出预算的帧，则很可能是某个不可合成的属性悄悄混入了滚动驱动的关键帧中。

为什么动画只在生产环境卡顿？

DevTools 在受控条件下进行性能分析，而它无法完全复现的变量是真实用户的环境——设备 CPU 档次、内存压力、并发活动。当卡顿报告在本地无法复现时，缺失的上下文通常就是原因所在。会话回放（Session Replay）能够捕获这些信息，让你在录制前知道需要模拟哪些条件。

按顺序运行四个面板——Rendering 确认问题，Performance 定位根因，Animations 隔离问题，Layers 评估代价——下一个卡顿的动画将不再是猜谜游戏。

常见问题

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.