很多页面的“卡”，不是因为逻辑复杂，而是因为动画做错了。
按钮悬停、弹层进入、列表过渡、滚动联动，看起来只是视觉细节，但只要动画属性选错、节奏设计不当，就会直接拖慢交互体验。
所以动画性能优化并不是“有空再做的锦上添花”，而是渲染层的重要基本功。
优先使用不会触发布局和重绘的属性
动画性能的第一原则非常明确：
- 优先使用
transform - 优先使用
opacity - 尽量避免直接动画化
width、height、top、left、margin
原因很简单：
transform和opacity更容易走合成阶段- 布局类属性更容易触发重排和重绘
很多掉帧问题，根本不需要复杂分析，只是属性选错了。
不要把“能动起来”误当作“动画可上线”
开发阶段最容易出现的误判是：
- 本机设备性能强
- 动画看起来能跑
- 就认为线上也没问题
但真实用户环境里，动画会叠加：
- 图片加载
- 滚动监听
- 阴影和模糊效果
- 多个组件同时进入动画
所以判断动画质量，不能只看单个 demo，要看它是否能在真实页面里和其他工作一起运行。
节奏设计和数量控制同样重要
动画性能并不只由属性决定，还与“同时发生多少动画”密切相关。
一个更稳的策略是：
- 首屏只保留最关键的 1 到 2 个进入动画
- 列表动画用错峰和分批方式，而不是一起动
- 危险的阴影、模糊、滤镜效果慎用在大面积区域
真正流畅的页面，通常不是动画更多，而是动画更克制。
合成层不是越多越好
很多人学到“合成层更快”之后，就会尝试到处加 will-change 或强制 GPU 加速。
这同样会带来问题：
- 内存占用增加
- 合成层管理成本变高
- 页面越复杂，收益越不稳定
will-change 应该是临时优化手段，而不是默认样式策略。
失败案例：列表进入动画做得很漂亮，但滚动体验被拖垮
一个典型案例是营销页或内容页：
- 所有卡片进入视口就触发位移和阴影动画
- 每张卡片都有模糊和缩放过渡
- 页面滚动时不断触发新的动画实例
结果是：
- 首次看起来很惊艳
- 用户继续滚动时开始掉帧
- 低端设备直接发热卡顿
问题不在 CSS 动画本身，而在于动画数量和触发策略没有被纳入性能约束。
调试动画性能时先看 3 件事
- 是不是用了高成本属性
- 同一时刻有没有太多动画一起跑
- 是否叠加了阴影、滤镜、大图和脚本计算
用 DevTools 时，重点观察：
- 是否频繁触发 layout
- paint 是否异常密集
- 主线程是否被脚本任务和动画一起占满
一份可直接复用的检查清单
- 是否优先使用
transform和opacity - 是否避免布局类属性的高频动画
- 是否限制首屏和滚动中的并行动画数量
- 是否谨慎使用阴影、模糊、滤镜等高成本效果
will-change是否只在必要时短期使用- 是否在真实页面和中低性能设备上做过验证
总结
CSS 动画性能优化的核心，不是“让所有效果都更快”，而是让动画在真实页面里仍然可控、可预期。属性选择、节奏控制、合成层策略和调试方法必须一起考虑，页面才不会从“好看”变成“难用”。
进一步阅读：
