CSS动画性能优化实战：从渲染管线到合成层，打造流畅动效

我之前负责过一个活动页的卡片翻转交互，上线当天就被测试小姐姐甩来一段录屏——动画在低端安卓机上卡成了PPT，帧率目测不到20fps。这就是CSS动画性能优化最典型的场景：效果看着很美，一上线就露馅。CSS动画的性能优化，核心其实就两件事——怎么让动画跑得足够流畅，以及怎么在流畅度和视觉美感之间找到那个不牺牲体验的平衡点。这篇文章不打算讲API怎么背，而是从浏览器渲染管线的底层逻辑出发，把我踩过的坑、验证过的方案、实测出来的参数全部摊开来说。

适合谁来读？如果你写过几个动画但总感觉"哪里不对劲"，如果你在项目里为了一张卡片翻转效果被老板一句"为什么这个页面像PPT"问住，如果你想要一套能直接落到代码Review和验收标准里的优化清单——这篇文章对你有用。

1. 为什么一个"看起来很简单"的动画会让页面卡成幻灯片

1.1 从浏览器渲染管线说起：每帧动画背后发生了什么

先说一个很多前端会忽略的事实：浏览器把一个元素的样式变化变成屏幕上的像素，不是瞬间完成的。它要经过一条固定的流水线，通常叫渲染管线。

简化来看，浏览器每一帧要依次做这几件事：

1. Style：根据CSS规则，计算出每个元素当前应有的样式。
2. Layout：计算元素的位置和尺寸。子元素的尺寸变了，父元素、兄弟元素可能都要跟着重算。
3. Paint：把元素的视觉内容（颜色、阴影、文字、背景等）绘制成图块。
4. Composite：把所有图层按正确的前后顺序合成为最终的屏幕画面。

我常用一个搬家类比来解释这四步：Layout相当于重新测量房间尺寸、决定家具摆哪；Paint相当于给墙刷漆、给沙发套布；Composite相当于给整个房间拍一张最终照片。如果你每次都把家具搬出搬进（触发Layout），那墙面也得重新刷（Paint），照片也得重新拍（Composite），整个人都要累瘫。但如果你只是在已拍好的照片上加一个会动的贴纸（只触发Composite），那就轻松得多。

CSS动画卡顿的根源，绝大多数时候不是"动画本身太复杂"，而是"动画触发的工作量太大"——让浏览器每一帧都把整条流水线从头走到尾。

这里必须引入一个关键概念：帧预算。正常的屏幕刷新率是60Hz，也就是每秒刷新60次，浏览器每一帧的工作时间大约只有16.67ms。一旦某一帧超时，可视画面就会卡顿或跳帧。如果你在一个低端手机上做动画，实际的预算可能只有10ms甚至更低，因为设备和系统本身就占用了不少资源。

所以，我们优化CSS动画性能，本质上是在做一件事：把每一帧要做的工作尽量推到流水线的末端阶段去完成，最好只做Composite这一步。

1.2 真正拖垮性能的三大元凶：布局抖动、重绘风暴、主线程阻塞

很多人在优化CSS动画时，第一反应是"把动画改成GPU加速"，但真正拖垮页面的往往不是单个动画，而是下面这三类问题。

第一类：布局抖动（Layout Thrashing）

这个词听起来专业，实际场景很常见：你在JS里做一个进度条动画，循环里先读一个元素的offsetWidth，再设置它的style.width，又读另一个元素的offsetHeight，又改它的height——读取和写入交错进行。浏览器为了保证每次读取到的值是最新的，只能在读取前强制做一次布局。于是你的循环每跑一次，就强制布局一次，动画自然就卡了。

javascript复制// 糟糕的写法：读写交织，触发大量强制同步布局
const bars = document.querySelectorAll('.bar');
for (let i = 0; i < bars.length; i++) {
  const currentWidth = bars[i].offsetWidth; // 读
  bars[i].style.width = (currentWidth + 10) + 'px'; // 写
  const textWidth = bars[i].querySelector('.label').offsetWidth; // 又读
  bars[i].querySelector('.label').style.fontSize = (textWidth / currentWidth) * 16 + 'px'; // 又写
}

正确的做法是先集中读取，再集中写入。虽然这更像是JS层的优化，但一旦你的CSS动画配合这种循环一起执行，布局抖动会被放大得特别明显。

第二类：重绘风暴（Paint Storm）

这个更常见。很多人喜欢给元素加box-shadow、filter滤镜或者border-radius来做动效。比如一个悬浮卡片，hover时box-shadow从0变成20px扩散，视觉上确实好看。问题在于，box-shadow的每一次变化都会导致大范围的绘制——每帧都在画阴影，阴影范围越大，Paint阶段的开销越高。同样的道理也适用于filter: blur()，它每一帧都要对整张图做模糊计算，代价极其高昂。

我在实际项目中见过一个极端案例：一个页面上有20多张卡片，每张卡片hover都有box-shadow扩散动画，结果在普通办公本上移动鼠标都能感觉到掉帧。后来把阴影改成一张预置的PNG图片，用opacity做渐变显示，性能立刻好了几个量级。

第三类：主线程阻塞（Main Thread Blocked）

CSS动画本身有很多是在合成线程上完成的，不受主线程JS阻塞影响。但当一个动画触发了Layout或Paint，那它就被绑在了主线程上。此时如果主线程正在处理一个大型同步JS任务，动画就必须等着。比如你打开页面，一个入场动画正要播放，同时接口数据返回后有一段非常重的数据处理逻辑，直接把主线程占死了——动画就会突然停顿一下，然后接着播。

排查这类问题最直接的手段是打开Chrome DevTools的Performance面板录一段性能数据，看帧时间线和长任务（Long Task）。我会在第五章的案例里具体讲怎么看。

2. 动画属性的"体能分级"：哪些属性天生流畅，哪些属性天生卡顿

2.1 只动 transform 和 opacity 的铁律

你可能已经听过那句"名言"：CSS动画性能优化，优先动transform和opacity。这句话不是玄学，它背后就是渲染管线阶段的差异。

我把日常开发中最常用的动画属性做了一张分级表，建议你直接当参考标准用：

为什么transform和opacity这么特殊？因为这两个属性的变化可以在合成阶段直接处理，不需要重新布局，大多数情况下也不需要重新绘制。浏览器会把这个元素单独提升为一个合成层，之后的变化完全由GPU来处理。主线程就算再忙，也很难影响这个动画的流畅度。

一个最简单的例子：让一个元素向右移动100px。

css复制/* 不推荐：触发完整渲染管线 */
.box {
  position: absolute;
  left: 0;
  transition: left 0.3s ease;
}
.box.is-moved {
  left: 100px;
}

/* 推荐：只触发合成 */
.box {
  transform: translateX(0);
  transition: transform 0.3s ease;
}
.box.is-moved {
  transform: translateX(100px);
}

视觉上两者几乎没区别，但性能差距可能达到一个数量级。左侧的left动画在移动端低端机上很可能掉帧，而transform版本即使同时播放十几个也稳如老狗。

同理，opacity代替visibility做淡入淡出也是这个道理。visibility的过渡只能瞬间切换，display的过渡根本不生效，而opacity可以做0到1的渐变动画，还全程只在合成阶段工作。

2.2 万不得已要动 width/height/top/left 时的替代方案

有人会问：有时候我就是要做一个高度展开的效果，菜单展开、折叠面板、手风琴，这些不就得改height吗？确实，这类需求绕不开布局属性的变化，但我们可以用技巧把"看起来像在改布局"的动画，实际翻译成"只在合成阶段工作"的动画。

方案一：FLIP技术

FLIP全称是First, Last, Invert, Play。核心思路是：

1. First：记录元素动画开始时的位置和尺寸。
2. Last：让元素直接跳到动画结束时的状态，记录结束时的位置和尺寸。
3. Invert：算出两个状态之间的差值，通过transform把元素"反向"移动回到起始位置。
4. Play：移除反转变换，用transform过渡到最终状态。

这样，从浏览器渲染的角度来看，整个动画过程从头到尾只动了transform，没有触发Layout。

下面是一个最简单的折叠面板实现思路：

javascript复制function animateCollapse(panel) {
  const first = panel.getBoundingClientRect();

  panel.classList.add('expanded'); // 直接切换最终状态
  const last = panel.getBoundingClientRect();

  const deltaX = first.left - last.left;
  const deltaY = first.top - last.top;
  const deltaWidth = first.width / last.width;
  const deltaHeight = first.height / last.height;

  panel.animate([
    {
      transformOrigin: 'top left',
      transform: `translate(${deltaX}px, ${deltaY}px) scale(${deltaWidth}, ${deltaHeight})`
    },
    {
      transformOrigin: 'top left',
      transform: 'none'
    }
  ], {
    duration: 300,
    easing: 'ease-out'
  });
}

注意，这里用的是element.animate()，也就是Web Animations API，而不是CSS transition。因为FLIP场景下我们经常需要在JS里动态控制起始帧和结束帧，CSS transition不是不能做，但写起来很别扭。WAAPI最终也是走合成线程，只要动画属性是transform就没问题。

方案二：用scaleY模拟高度展开的"假象"

如果只是需要一个视觉上的展开效果，不需要真实撑开文档流，那可以用transform: scaleY()来实现。

css复制.menu {
  transform: scaleY(0);
  transform-origin: top;
  transition: transform 0.3s ease;
}
.menu.open {
  transform: scaleY(1);
}

这个方案的坑在于：scaleY只是视觉上缩放，元素实际占据的空间没有变。如果原菜单是三级联动，缩放后子元素的文字也会被压扁。解决办法是把文字反向scale回去，但这就复杂了。所以我的建议是：纯装饰性的展开效果可以用scaleY，涉及真实文本可读性和布局调动的场景还是用FLIP。

方案三：如果必须动布局属性，缩小爆炸半径

有些场景无论如何都要改真实布局。这时你的优化目标就变成：让布局变化的"爆炸半径"尽可能小。

什么叫爆炸半径？你改了A元素的宽度，B、C、D全都跟着重排，这就是半径大。优化思路包括：

• 让动画元素脱离文档流（absolute / fixed），避免影响其他元素。
• 用contain: layout或contain: paint声明，告诉浏览器这个元素内部的变化不要传导到外部。这个CSS属性平时关注的人少，但在动画场景里很实用。
• 每次动画之前先测量好所有尺寸，动画期间不要再读取DOM布局信息。

3. 合成层与will-change：给浏览器的"优先级调度"

3.1 合成层的前世今生：GPU合成、层爆炸与层提升

聊CSS动画性能，绕不开"合成层"这个概念。

浏览器在处理页面时，会把一部分元素独立成单独的图层，然后在合成阶段把这些图层拼起来。这个拼图的工作，就是GPU合成，速度非常快。我们想让动画只触发Composite，本质上是希望这个元素已经被提升为独立合成层。

哪些情况会让浏览器自动给元素提升合成层？

• 元素有transform或opacity动画
• 元素有transform: translateZ(0)或translate3d(0,0,0)
• 元素有will-change属性且值可合成
• 元素是video、iframe、canvas
• 元素有position: fixed
• 元素被某种复杂样式影响（比如某些filter属性）

所以网上流传着"加一句translateZ(0)就能启用GPU加速"的说法。这句话本身没错，但只对了一半。它只解决"提升合成层"这一步，如果你的动画属性是width/height/box-shadow，即使元素在合成层上，该触发的Layout和Paint一样会触发。换句话说，合成层只是"助跑"，方向不对照样跑不快。

更坑的是，合成层不是免费的。每个合成层都会占一块独立的内存，层越多，内存开销越大，合成阶段的工作量也越大。如果你给页面上几百个元素都加上translateZ(0)强制提升，很容易制造出"层爆炸"——内存占用飙升、滚动卡顿、甚至浏览器直接崩溃。

我见过一个真实案例：一个移动端宫格页面，给每个宫格图标都加了translateZ(0)想优化点击动效，结果页面在部分安卓机型上直接白屏。后来排查是GPU内存占用超限，浏览器直接把整个页面给kill了。

所以合成层的使用原则是：动画元素该提升就提升，静止元素不要滥提升。 我的习惯是只给正在播放动画的元素手动提升，动画结束立刻移除。

3.2 will-change 的正确使用姿势与常见误区

will-change这个属性就是用来手动告诉浏览器："这个元素即将改变，你提前做好优化准备。"

最常见的场景是hover时有一个transform缩放动画。你可以在元素进入动画前设置will-change: transform，动画结束再移除。

css复制.card {
  transition: transform 0.2s ease;
}
.card:hover {
  transform: scale(1.05);
}

如果只在hover时写transform，浏览器需要等到第一帧计算样式时才知道这个元素要变化，存在一定延迟。提前设置will-change可以让浏览器预先提升合成层，动画启动更丝滑。

正确的实践是在JS里控制will-change的生命周期：

javascript复制const card = document.querySelector('.card');

card.addEventListener('mouseenter', () => {
  card.style.willChange = 'transform';
});

card.addEventListener('animationend', () => {
  card.style.willChange = 'auto';
});

// 对于transition，用transitionend或setTimeout移除

will-change最常见的几个误区：

误区一：will-change越多越好。 完全错误。will-change会占用合成层内存，滥用等于主动制造层爆炸。

误区二：will-change直接写在CSS里挂着不管。 如果一个元素的will-change长期驻留，浏览器会一直为它保留合成层资源，即使它根本不动画。我见过有同学在全局样式里写.el { will-change: transform; }，用了几个月都没发现性能问题，其实是浪费了大量GPU内存。

误区三：will-change能拯救任何动画。 不行。will-change只是提升优化"准备"，它不能让一个触发Layout的动画免于Layout。如果你在动画里改width，就算will-change写了十个属性，也逃不掉布局计算。

最后强调一点：will-change不是一个用来"兜底"的属性。你首先要保证动画本身用的是高性能属性，然后才轮到will-change去加速启动过程。

4. 复杂动效的性能预案：从需求评审到代码落地的取舍链

4.1 动效分级策略：哪些动画值得做，哪些动画要砍

经过前面这么多技术层面的拆解，你可能会觉得优化CSS动画纯是技术活。但我在项目里待久了，反而觉得取舍能力比写代码能力更重要。一个动画做不做、做多复杂，从需求评审阶段就该有判断标准。

我习惯把动效分成三级，每一级的取舍标准完全不同：

判断一个P2动效到底做不做，我一般问三个问题：

1. 这个动效对用户理解当前操作有没有帮助？如果只是"好看"，要警惕。
2. 这个动效能不能用transform和opacity实现？如果必须连续触发大量layout或paint，说明大概率是重动效。
3. 这个动效在页面上会不会同时出现多个？同时有十几个金币在飞，和页面里有十几个按钮hover动画，性质完全不同。

拿"粒子背景"举例。一个80个粒子的飘浮动画，如果每个粒子都是独立的DOM元素，用left/top做轨迹，在桌面端还能凑合，在移动端基本是灾难。但如果把粒子合并到一个canvas里，用canvas绘制而不是CSS动画，反而能轻松跑到60fps。所以P2动效不是不能做，而是要明确"成本上限"。

4.2 降级方案的工程实现：降帧、简化、关停

再精细的性能预算，也扛不住不确定的用户设备。所以你必须有一套"降级方案"。

最标准的降级手段：prefers-reduced-motion。

这是CSS媒体查询，用来检测用户是否在系统层面开启了"减少动态效果"。如果用户开了这个选项，说明ta明确希望减少动画。我们的代码应该尊重这个偏好。

css复制@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

用0.01ms而不是0ms，是为了避免某些浏览器在duration为0时直接不触发transitionend事件，导致业务状态无法正确衔接。这是我踩过的一个小坑。

同样，在JS里也可以用matchMedia监听这个偏好：

javascript复制const motionMedia = window.matchMedia('(prefers-reduced-motion: reduce)');

if (motionMedia.matches) {
  document.documentElement.classList.add('no-animation');
}

motionMedia.addEventListener('change', (e) => {
  document.documentElement.classList.toggle('no-animation', e.matches);
});

降帧方案。如果你的动画在高帧率下很顺滑，但在低端机上掉帧严重，可以考虑检测设备的实际帧率，动态关闭一些高成本装饰动画。一个粗暴但有用的做法是：用requestAnimationFrame统计一段时间内实际能跑到多少帧，如果连48fps都达不到，就不再渲染P2级装饰动画。

javascript复制let lastTime = 0;
let frameCount = 0;
let totalFrames = 0;

function measureFPS() {
  const now = performance.now();
  const delta = now - lastTime;
  lastTime = now;
  if (delta > 0) {
    frameCount++;
    totalFrames += 62 / delta; // 近似每秒帧数
  }
  if (performance.now() > startTime + 3000) {
    const avgFps = frameCount / 3;
    if (avgFps < 48) {
      document.documentElement.classList.add('low-end-device');
    }
    return;
  }
  requestAnimationFrame(measureFPS);
}

const startTime = performance.now();
requestAnimationFrame(measureFPS);

这种做法不是标准方案，但它在真实项目里帮我拦下了很多"低端机上的PPT"。你可以把它理解成一个极简的"设备性能探测器"。

工程层面的兜底开关。除了自动降级，我强烈建议给所有非核心动效加一个"关停开关"。可以是后台配置，也可以是页面角落的一个"减少动画"按钮。不要觉得这多余——很多用户确实会因为页面动效太多而感到头晕，给他们一个关闭的入口，既提升可访问性，也减轻了性能压力。

5. 一个真实案例的完整调优链路：从23ms到6ms

5.1 第一步：定位瓶颈——用Performance面板和帧率监测

理论讲了不少，下面用一个我实际参与过的项目案例，把整个调优过程走一遍。

背景是一个电商活动页。页面上有几个模块：

• 顶部有一个持续播放的"金币雨"动效
• 中部有卡片翻转展示商品
• 底部是一个进度条，进度到100%时触发一个彩带动画

问题：低端安卓机上金币雨一开，整个页面滚动几乎卡死；卡片翻转有明显的延迟感；进度条动画倒是还算流畅，但会因为金币雨的卡顿被拖累。

第一步，用Chrome DevTools的Performance面板录制一段10秒左右的交互过程。重点看这几个指标：

1. 帧时间线（FPS chart）——出现大量红色长条，说明有掉帧。
2. 帧耗时（Frame Time）——平均帧耗时达到23ms左右，远超出16.67ms的预算。
3. 主线程活动——Layout和Paint的时间柱占了很大比例。

看下来最触目惊心的是：金币雨模块的每个金币都用了left和top来做位移动画，而且是通过JS的setInterval每帧修改style来实现的。代码逻辑大概是这样的：

javascript复制// 优化前的金币雨逻辑（示意）
const coin = document.createElement('div');
coin.className = 'coin';

function fall(coin) {
  let y = -50;
  const timer = setInterval(() => {
    y += 8;
    coin.style.top = y + 'px'; // 每帧触发layout
    if (y > window.innerHeight) {
      clearInterval(timer);
      coin.remove();
    }
  }, 16);
}

这段代码有两个大问题：一是setInterval(..., 16)不保证16ms执行，遇到主线程繁忙会堆积；二是每帧都改top，直接触发完整的Style、Layout、Paint、Composite流程。页面上一共同时存在30多个金币，等于每帧要做30多次完整布局计算。

除此之外，金币还用了box-shadow来做光晕效果，进一步放大了Paint阶段的开销。

定位问题的关键结论：这不是"CSS动画性能优化"的问题，而是"用JS加CSS属性写出了最差的动画实现"。优化空间极大。

5.2 第二步：逐级优化——属性替换、图层合并、节流触发

定位清楚问题后，我做了几轮优化。

第一轮：把金币雨从JS驱动改成CSS动画驱动。

CSS动画的好处是浏览器可以根据渲染进度自动调度，而且transform和opacity可以交给合成线程处理。单个金币的样式改成这样：

css复制.coin {
  position: absolute;
  top: 0;
  left: 0;
  opacity: 0;
  will-change: transform, opacity;
  animation: coin-fall 2.4s linear forwards;
}

@keyframes coin-fall {
  0% {
    transform: translate3d(0, -60px, 0) rotate(0deg);
    opacity: 0;
  }
  8% {
    opacity: 1;
  }
  100% {
    transform: translate3d(130px, 70vh, 0) rotate(360deg);
    opacity: 0.6;
  }
}

注意几个细节：

• 动画轨迹用translate3d，其中X轴方向写死了一个偏移量，模拟金币下落时向右飘。这里不写0是因为视觉上更自然。
• Y轴用了70vh，这样在不同屏幕尺寸下都能落到屏幕底部附近。
• will-change只在金币创建时带一下，动画结束会移除。
• 金币的下落位置变化，用CSS变量或者动态修改animation-delay来控制随机感，避免所有金币排着队往下掉。

第二轮：去掉box-shadow，改用径向渐变做光晕。

box-shadow的开销在大量小元素上会被放大。金币尺寸只有24px左右，用box-shadow做光晕完全可以用background: radial-gradient()替代。

css复制.coin {
  background: radial-gradient(circle at 35% 35%, #ffe699, #f4b400);
  border-radius: 50%;
}

视觉上几乎一样，但绘制开销大幅下降。这是很多人在做粒子类动效时的盲区——他们不知道小元素的box-shadow其实非常贵。

第三轮：限制同时存在的动画元素数量。

原来的逻辑是每100ms创建一个金币，不销毁直到落出屏幕，所以金币数量越来越多。我改成"池化"策略：固定创建20个金币DOM，循环复用。一个金币动画结束后，立即给它的animation重新赋一个新延迟，让它从顶部重新落下。这样DOM数量封顶，内存开销稳定，合成层数量也可控。

第四轮：把进度条和卡片翻转的动画触发时机错开。

金币雨是持续动画，卡片翻转是交互动画，进度条是加载动画。三者同时跑的时候，即使每个动画本身已经优化，叠加起来仍可能超过帧预算。我把金币雨在页面滚动到其他模块时暂停，只保留当前视口内的装饰动画。具体做法是监听IntersectionObserver，离开视口就断开动画，回到视口再恢复。一个简单的实现：

javascript复制const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (!entry.isIntersecting) {
      entry.target.classList.add('paused');
    } else {
      entry.target.classList.remove('paused');
    }
  });
}, { threshold: 0.1 });

observer.observe(coinRainContainer);

配合CSS的animation-play-state: paused，就能优雅地暂停和恢复。

做完这四轮优化后，再用Performance面板录制相同场景，帧耗时从23ms降到了6ms左右，也就是实际帧率稳定在60fps以上。更直观的体验是：低端安卓机上滚动页面不再有那种"拖泥带水"的黏滞感。

5.3 第三步：验证与防回退——把性能预算写进CI

优化完还不够，更怕的是"优化一时爽，回退火葬场"。我见过太多项目，上线时性能极佳，三个月后被人加了一个"小小的阴影效果"，整页又开始卡。

所以我们把性能验证沉淀成了三件事。

第一，手工验证清单。

每次改动动效相关代码，都要在待发布浏览器上做一轮固定动作：

• 打开Performance面板录制10秒，确认帧耗时没有连续超过16.67ms。
• 切换至CPU 4x/6x降速，模拟低端机。
• 用移动设备模拟器或真机跑一遍所有P0和P1动效。

第二，自动化性能预算。

在CI里接入Lighthouse CI，对关键页面设置性能预算。比如Total Blocking Time（总阻塞时间）不超过200ms，Lighthouse Performance分数不低于85。一旦动效相关代码导致性能回退，CI直接红灯，不允许合并。

bash复制lighthouse https://staging.example.com \
  --only-categories=performance \
  --budget-path=./budget.json \
  --output=json

budget.json里可以这样配置：

json复制{
  "timings": [
    {
      "metric": "total-blocking-time",
      "budget": 200
    },
    {
      "metric": "largest-contentful-paint",
      "budget": 2500
    }
  ]
}

第三，代码Review里的动效检查项。

我在团队里推动了一套简易的动效Review规则：

• 动画属性是否只用了transform和opacity？如果出现top/left/width/height，必须说明原因。
• 是否包含box-shadow或filter动画？如果没有充分的理由，标记为"警告"。
• 是否同时播放多个高成本动画？如果是，是否有限流或视口暂停策略？
• 是否处理了prefers-reduced-motion？

这套规则不复杂，但它能从源头拦住80%的性能回退。不要迷信某个工具能自动发现问题，很多时候人肉Review才是最后一道防线。

我自己在这些项目里反复踩坑后，最大的体会是：CSS动画的性能优化，七分靠规划和取舍，三分靠代码。技术方案再完美，如果一开始就做了个高成本的动效设计，后面再怎么优化都是亡羊补牢。所以我的习惯是：拿到一个动效需求，先不着急写CSS，先在脑子里把它的生命周期走一遍——它会不会长时间存在？会不会和其它动效叠加？用户设备如果很弱，它值得被保留吗？想清楚这几个问题，再做技术选型，写出来的动画至少不会让人想摔手机。

最后再分享一个小技巧：在做低配设备适配时，不要只看"有没有掉帧"，要看"掉帧后是平滑降级还是突然跳跃"。一个用transform做的动画，即使GPU资源不足，浏览器也倾向于自动降帧，视觉上是"变慢"而不是"卡顿"；而一个用left/top做的动画，掉帧时是直接跳变，视觉上是"一顿一顿"。这中间的体验差距，用户可能说不清，但感受非常明显。这也是为什么我一直强调，能走合成线程的动画，就坚决不要拖回主线程。