CSS3 animation性能优于GIF的关键在于仅修改transform和opacity可触发GPU合成，避免重排重绘；而GIF强制周期性重绘且无法硬件加速，但小图标或无CSS环境时GIF仍具轻量优势。
CSS3 animation 在绝大多数场景下比 GIF 图性能更好，但不是绝对——关键看你怎么用、用在哪儿、动的是什么属性。
为什么 GIF 动画容易拖慢页面
GIF 是位图序列，浏览器必须每帧解码并重绘整个图像区域。它会强制触发周期性重绘（repaint），且无法利用 GPU 合成层。常见问题包括：
- 即使 GIF 静止在页面上，某些浏览器仍会持续轮询解码（尤其在 tab 切换后）
- 不支持
will-change或transform: translateZ(0)等合成提示，无法主动提升图层 - 缩放时像素拉伸、锯齿明显，
image-rendering: pixelated仅部分生效 - 无法响应
prefers-reduced-motion，对无障碍不友好
为什么 animation 不一定就快
很多人以为用了 animation 就自动高性能，其实错在动了不该动的属性：
- 用
left/top+position: relative做位移 → 触发重排（reflow），卡顿立现 - 动画中频繁修改
width/height/margin→ 每帧都重算布局 - 没加
will-change: transform或未触发硬件加速 → 仍在主线程绘制 - 在低功耗设备上用
steps(60)播放超大雪碧图（spritesheet）→ 内存暴涨、解码压力大
真正能拉开性能差距的写法
高效 CSS3 帧动画的核心是：只动 transform 和 opacity，其他全交给合成器。
立即学习“前端免费学习笔记（深入）”；
- 位移用
transform: translateX()而非left；缩放用scale()而非width/height - 雪碧图动画优先用
background-position+steps(N)，但确保背景图尺寸可控（建议单帧宽高 ≤ 2048px） - 加
will-change: transform提前告知浏览器该元素将动画，避免首帧掉帧 - 用
@keyframes控制transform: translateY()移动整个 sprite 容器，比逐帧切 background 更稳
什么时候还该用 GIF
不是所有场景都要“技术正确”。GIF 仍有不可替代的轻量级价值：
- 极小图标动效（如 loading spinner，≤ 24×24px）：GIF 体积可能比等效 CSS 动画 + base64 图片更小
- 无 JS/CSS 支持环境（如邮件客户端、旧版 Outlook）：GIF 是唯一可靠方案
- 设计师直接交付的动效预览稿：快速嵌入验证，不值得为临时需求搭 CSS 动画结构
真正容易被忽略的点是：性能瓶颈往往不在“选 GIF 还是 animation”，而在是否让动画脱离主线程——哪怕一个 transform 动画，如果父容器有 filter: blur() 或大量 box-shadow，照样卡。别迷信语法，盯住 DevTools 的 Rendering 面板看合成层和帧率。
