SVG替代Canvas动画可显著减小体积，因其为可gzip高效压缩的矢量文本，且缩放无损；实操建议优先用SVG+CSS或Web Animations API实现图标、转场等动效，并避免内嵌未压缩Base64图片。
用 SVG 替代 canvas 动画帧能显著减小体积
纯 canvas 绘制的逐帧动画（比如导出为 JS + 图片序列）往往打包后体积巨大，尤其含多分辨率图或未压缩纹理时。而矢量驱动的 SVG 动画本身是文本，可被 gzip 高效压缩，且缩放无损。
实操建议：
• 把图标、转场、加载动效等规则图形优先改用 SVG + CSS @keyframes 或 SMIL（注意：Chrome 已弃用 SMIL，推荐用 Web Animations API 或 GSAP 控制 SVG 属性）
• 导出设计稿时，在 Figma / Adobe Animate 中选「导出为 SVG」而非「导出为 PNG 序列」
• 避免在 SVG 中内嵌 Base64 图片；如必须，先用 svgo 压缩再嵌入
ffmpeg 命令行压缩 WebM 动画比 GUI 工具更可控
很多团队用剪映、Premiere 导出 WebM，但默认参数冗余严重，文件常比必要大 2–3 倍。直接调用 ffmpeg 可精准控制码率、关键帧间隔和色度采样。
常见错误现象：导出后动画卡顿、首帧延迟高、体积不降反升——多因未设 -g（GOP 大小）或用了 -crf 10 这类过高质量参数。
实操建议：
• 简单动效（如按钮 hover、加载条）用：
ffmpeg -i input.webm -c:v libvpx-vp9 -b:v 128k -maxrate 128k -bufsize 256k -g 48 -qmin 30 -qmax 42 -pix_fmt yuv420p -c:a libopus -b:a 32k output.webm
• 关键帧间隔
-g 48 对应 2 秒（按 24fps），避免过长 GOP 导致 seek 卡顿•
-qmin/-qmax 比 -crf 更适合短动画，防止局部细节过度压制
lottie-web 的 renderer: 'svg' 比 'canvas' 小 40% 以上
同一份 .json 动画资源，渲染方式不同，最终 JS 执行体积和 DOM 开销差异极大。renderer: 'canvas' 需载入完整 canvas 渲染器逻辑，且每帧触发重绘；而 renderer: 'svg' 复用原生 DOM，体积更小、CSS 可控性更强。
使用场景：Lottie 用于品牌动效、空状态、表单反馈等非游戏类交互
实操建议：
• 初始化时显式指定：
lottie.loadAnimation({\n container: document.getElementById('anim'),\n renderer: 'svg',\n loop: false,\n autoplay: true,\n path: 'anim.json'\n});• 禁用不需要的功能：设
ignorePrevFrame: true（跳过帧差计算）、subframeEnabled: false（禁用亚像素插值）• 若动画不含蒙版/遮罩，可在导出前在 Lottie Files 或 Bodymovin 插件中关闭
Include masks and mattes
不要对已压缩的 .webm 或 .json 再套一层 gzip
现代构建工具（如 Webpack/Vite）默认对静态资源启用 gzip/brotli 压缩，但若原始文件已是高压缩比格式，二次压缩不仅无效，还可能因元数据膨胀反而变大。
容易踩的坑：
• 把 ffmpeg 导出的 .webm 丢进 gzip -9，结果体积 +0.3%
• 用 terser 压缩已由 Bodymovin 输出的 .json，JSON 本就是紧凑文本，Terser 主要优化 JS 语法，对它几乎无收益
• Nginx 配置中开启 gzip_types application/json video/webm;，但 .webm 是二进制流，gzip 对它效果极弱，还增加 CPU 开销
性能影响：服务端对已压缩资源做额外编码，会提高 TTFB，尤其在高并发下
立即学习“前端免费学习笔记（深入）”；
