CSS 动画性能优化：will-change、composite layer 与 60fps 的保障策略

一个很常见的场景：页面本身不复杂，只是加了一个卡片翻转过渡，结果在普通安卓机上明显卡顿。明明用的是 CSS 动画，没有 JavaScript 参与，为什么还会掉帧？这类问题通常不是“动画代码写错了”，而是对浏览器渲染机制缺少整体认识。

要优化 CSS 动画性能，只记“用 transform 代替 left/top”这类口诀不够。will-change、composite layer、60fps 被频繁提起，但如果不了解浏览器每一帧里做了什么，很容易走极端：要么乱加 GPU 加速，要么完全不敢用。

60fps 到底意味着什么

60fps 并不是一个随意的指标。大多数显示器每秒刷新 60 次，一帧的预算大约是 16.7ms。想要动画看起来顺滑，每一帧的渲染任务都得在这段时间内完成。一旦某一帧超过了这个预算，画面就会卡一下。但真正伤害体验的不是偶尔一帧长耗时，而是帧耗时的不稳定。

这里有一个很容易被忽视的结论：动画性能优化的重点是“减少长任务”，而不是纯粹追求平均帧率。如果一秒钟内前 58 帧都很轻松，后两帧因为 layout 或 paint 巨响而耗时 100ms，用户依然会看到不自然的停顿。所以，我们需要知道动画背后触发了哪些昂贵的渲染阶段。

把一帧 16.7ms 的时间放在渲染上，其实它还要被拆成好几段：JavaScript 执行、样式计算、布局、绘制、合成。任何一段被一条长任务占满，都会压缩后面阶段的剩余时间。这也是为什么“减少主线程长任务”在动画优化里那么重要。

渲染管线：为什么 transform 比 left 更流畅

浏览器渲染一帧大致会经过样式计算（style）、布局（layout）、绘制（paint）和合成（composite）。不同的 CSS 属性变化会走不同的路径。

• 修改 left、width、height 这类几何属性，浏览器要重新进行布局计算，再走绘制和合成。
• 修改 color、background-color，可以跳过布局，但通常仍需要重绘。
• 修改 transform 和 opacity，在元素处于独立合成层的情况下，有可能直接把每帧的变化交给合成器完成，不用重新布局，也不用重新绘制原始内容。

这也解释了为什么“动画里优先使用 transform 和 opacity”是一条可靠的建议。但要小心，这句话成立的前提是目标元素自己是一个合成层。如果元素还在普通图层上，transform 动画可能仍然需要先把内容绘制一遍。这里就需要引入 composite layer 的概念。

很多移动端列表页里会出现类似的写法：交互时用 margin-left 做位移，滚动时浏览器不断重排后续每一个元素。问题并不是动画本身复杂，而是这个动画属性把相邻元素全都拉进了 layout 阶段。

composite layer：GPU 加速不是免费的

composite layer，也常被称为合成层或图层。当浏览器把一个元素提升到独立图层后，后续对该图层的变换就可以由合成器单独处理，这也是 GPU 加速的核心来源。提升图层的原因很多，will-change 只是其中一种主动声明的方式，还有像 transform: translateZ(0)、opacity 动画、filter、video、某些 fixed 定位元素等也会触发。

当动画发生在合成层上时，浏览器可以让合成器线程接管 transform 和 opacity 的变化，主线程不用每一帧都参与。这就是为什么即使页面 JavaScript 主线程繁忙，部分 CSS 动画依然能够保持相对流畅。但反过来，如果主线程每帧都必须触发布局或重绘，合成器线程也没法帮上忙。

但很多团队在这里会犯同一个错误：看一眼 DevTools 推荐，或者网上的科普，就立刻给所有要动画的元素加 transform: translateZ(0)。看起来每一帧都是 GPU 在轻量化移动，实际上却忘了每个合成层都要占用独立的内存 buffer。元素越多，合成层数越庞大，GPU 内存交换和带宽开销反而成为新的瓶颈。

一个后台 dashboard 里常见的情况：几十张图表卡片同时有 hover 浮层的效果，开发为了动画流畅，给所有卡片都加了 translateZ(0) 强制提升。结果页面一开，GPU 内存占用明显上涨，在性能较弱的平板上滚动整个页面时，反而出现了更频繁的掉帧。这个例子说明，强制提升不是性能保证，而是把成本从主线程挪到了 GPU，一旦控制不好，任务根本没有变少。

will-change：要提前说，而不是一直说

will-change 用来告诉浏览器某个属性可能发生变化，让浏览器提前做优化。比如动画开始前设置 will-change: transform，真正动画时就不必临时创建合成层，能减少首帧卡顿。这听起来很好，但关键在于用词：“可能发生变化”。

如果把 will-change 直接写在基类样式里，等于告诉浏览器“这个元素随时都可能动”。于是从页面加载开始，每个元素都拥有了常驻合成层。这个状态持续得越久，内存和耗电压力就越大，而且可能引发浏览器额外的重绘优化行为。

另外，不要以为 will-change 写上某个属性，浏览器就一定会做分层的优化。它的作用更像是一个提示，浏览器会结合当前元素的状态决定是否创建合成层。而且，如果你声明的是 left，浏览器可能提前做的是布局方面的准备，这并不能让动画避开重排。真正最常用的声明还是 will-change: transform 或 will-change: opacity，因为这两个属性才是合成器能够独立处理的。

正确的用法是给动画过程一个短窗口。比如在动画开始前添加一个状态类，结束后再移除。以 React 或 Vue 中的过渡动效为例，可以在进入/退出阶段的钩子函数里控制这个类名。下面是一个简化的 CSS 表达：

.card {
  transition: transform 0.3s ease;
}

/* 动画执行前添加，结束后移除 */
.play .card {
  will-change: transform;
}

.card.done {
  will-change: auto;
}

这里的重点是 will-change: auto 会清掉优化的准备。实际开发中，冒泡事件触发的动画也可以用 setTimeout 延迟一小段时间移除。

动画优化中的几个常见坑

除了滥用 GPU 加速，实际项目里还有几个高频误区，值得单独列出来：

• 以为 will-change 能替代 transform/opacity。它只是预声明，真正跑动画还是尽量走合成阶段，否则照样触发布局和重绘。
• 在动画过程中改变元素尺寸或位置，同时大量使用 box-shadow、filter。即使写了 transform，滤镜的逐帧变化也会造成昂贵的绘制成本。
• 使用 JavaScript 直接操作 style.left 或 style.top，比如一些旧的动画库，仍然会触发布局，导致每一帧都有大量 layout 工作。
• 大面积使用 backdrop-filter。它看起来是合成层，但在部分浏览器上会产生很重的逐帧采样成本，需要谨慎评估。

常见动画属性的性能表现对比

下面这个表格总结了几类属性或写法的触发路径。它给了一个判断依据，但也需要结合实际元素和浏览器实现来理解，因为不同浏览器在底层合成策略上存在差异。

如果发现掉帧，怎么定位是哪一个阶段的问题

Chrome DevTools 的 Performance 面板是最直接的入口。录制一段包含动画的交互，然后看 Main 主线程里每一帧的任务分布。如果 Layout 和 Update Layout Tree 耗时突出，基本可以确定这个问题由几何属性或结构变化引起。如果 Paint 区域很大、耗时很长，则需要考虑是不是绘制复杂效果，比如模糊、阴影或大面积渐变。

还可以在 Rendering 面板中打开 Paint flashing 和 Frame Rendering Stats。Paint flashing 会高亮重绘区域，Frame Rendering Stats 或 Layout Shift Regions 可以配合观察。另一个有用的工具是 Layers 面板，它能列出当前页面所有合成层。打开这里，你会直观地看到页面已经有多少层，以及哪些元素因为什么原因被提升成独立层。排查时如果发现排列紧密的一串卡片全部拥有独立图层，那就是一个危险信号。

如果手边没有低端真机，也可以先用 Chrome DevTools 的 CPU 降速功能，比如模拟 6 倍降速，然后重新录制 Performance。这能放大掉帧问题，让瓶颈段更容易暴露。

落地建议：让优化成为代码评审的一部分

把视角拉远一点，CSS 动画性能优化不是某一个属性的事，它应该渗透到组件设计和代码评审中。这里给一份可以参考的落地清单，适用于大多数中后台和 H5 场景：

• 动画属性默认选择 transform/opacity；如果必须动画尺寸或阴影，想好替代方案。
• 将 will-change 声明在一个可添加/移除的类上，跟随动画生命周期。
• 不滥用 translateZ(0)；确定某个合成层真正被连续动画使用时，再考虑保留。
• 用 Performance 和 Layers 面板做定期检查，尤其在大列表、图表、地图场景。
• 在目标用户的中低端设备上真机体验，观察滚动和动画的流畅度。

如果你正面对一个已经卡顿的页面，建议先不要急着加任何“优化属性”。打开 DevTools，记录一次掉帧，确认瓶颈在 layout、paint 还是 composite。如果是在 layout，就检查有没有动画属性是 left、top；如果在 paint，就减少阴影和滤镜；如果独立图层太多，就收敛强制提升和 will-change。每一类问题都有对应的解法，但前提是你要先看证据。

回到文章开头那个卡片翻转掉帧的例子。问题的答案并不是简单一句“用 transform 就好”。只有当你注意到，卡片翻转动到的同时，还触发了周围元素的布局变化，或者在动画期间给整个容器额外加了一层 filter，才理解了性能问题的本质。CSS 动画性能优化的核心，是让浏览器每一帧都只做最必要的工作，把剩余主线程留给真正的页面逻辑。