五个演示动图的瘦身前后数据，含两类我没动的

五个演示动图，改之前 269 KB，改之后 82 KB。这篇把每个文件的前后数据、压缩时的参数判档、以及为此付出的代价都列清楚，不做「优化后性能大幅提升」这种没有单位的表述。

改之前是什么样

首页五个演示动图，都是屏幕录制转出来的 GIF：界面大部分不动，只有进度条和光标在移动。尺寸从 560×315 到 720×405，帧数 24 到 40 帧。

文件	尺寸 · 帧数	原始体积
install	560×315 · 24 帧	56.0 KB
config	640×360 · 30 帧	62.7 KB
deploy	720×405 · 40 帧	46.6 KB
debug	600×338 · 28 帧	33.0 KB
metrics	680×383 · 34 帧	70.7 KB
合计		269.0 KB

改了什么

一句话：只做减色和帧间差分，不动尺寸、不动帧率。

这是我给自己定的边界。减尺寸会让界面上的小字糊掉，降帧会让光标移动变得一顿一顿——这两样都在改变内容本身，而我要的只是同样的画面占更少的空间。

工具用的是一个浏览器端的动图工坊。选它有个很现实的原因：这些截图里有内部控制台的界面，我不想把它们传到任何服务器上。这个工具的拆帧和重编在浏览器本地完成，我全程开着 F12 的 Network 面板，五个文件逐个过一遍，没有出现一条 POST 请求。这一点不用信我，你自己按 F12 就能验。

改之后的数据

文件	原始	压后	降幅	判档
install	56.0 KB	15.8 KB	−71.8%	保持 GIF · 64 色
config	62.7 KB	17.8 KB	−71.6%	保持 GIF · 64 色
deploy	46.6 KB	15.5 KB	−66.7%	保持 GIF · 64 色
debug	33.0 KB	11.6 KB	−64.8%	保持 GIF · 64 色
metrics	70.7 KB	21.3 KB	−69.9%	保持 GIF · 64 色
合计	269.0 KB	82.0 KB	−69.5%

五个文件全部被判到 64 色。这不是我设的，是工具按画面内容自动定的——扁平配色的 UI 录屏，64 色足够，肉眼看不出和原图的差别。

有意思的是 deploy 那个文件最大（720×405、40 帧）却不是原始体积最大的。原因是它的界面静止区域占比最高，帧间差分省下来的最多。这也解释了为什么降幅不是按尺寸排的——决定压缩空间的是静止像素占比，不是分辨率。

代价是什么

代价一：色数从 256 降到 64。 扁平界面上看不出来，但如果你的演示动图里有渐变背景、有照片、有半透明叠加，64 色会出色带。我这五个都是纯 UI，所以没事。

代价二：多了一道流程。 以后每次更新演示动图，都得记得压一遍再传。我把这一步写进了发布前的检查清单，不然一定会忘。

没有付出的代价： 尺寸、帧率、播放节奏都没动，原始帧时长和循环设置被完整保留了下来。这一点我特意确认过——录屏的节奏如果被改掉，演示就失真了。

两种情况我没压

第一种：README 里那两个从视频转出来的动图。 实拍画面、有渐变、每帧都在变，压之前我先试了一个，体积基本没动。这类内容本来就不该做成 GIF，我的处理是换成视频标签，不在这次瘦身范围里。

第二种：组件库自带的加载动画。 这些是第三方资源，本来就已经优化过了。我试着压了一个 2 KB 的 spinner，只降到 1.5 KB，省下的 500 字节还不够我记一条 changelog 的。

值不值

269 KB 降到 82 KB，省了 187 KB。说实话，对一个日访问量三位数的文档站来说，这个绝对值小到不好意思拿出来说。

但那天在地铁里等着首屏出来的几秒，是真实的。一个人做产品，很多决定就是这么来的——不是算出来的，是自己被自己做的东西膈应到了。

但我认为值，理由有两条：一是这些动图全在首屏，弱网下它们和首屏渲染是抢带宽的；二是这件事是一次性的——我花了大概二十分钟，之后每次新增动图顺手压一下就行。

反过来说，如果你的动图在二级页面、或者本来就走懒加载，这个优化的优先级可以往后放。别为了 187 KB 去改架构，那不划算。

边界

上面这组数字来自我自己的文档站素材，全部是扁平配色的 UI 录屏。换一批画面性质不同的动图，降幅会完全不同——同一套操作在渐变横幅上只省了 7.9%，在满屏噪点的动图上一点没省。所以这组数据能给你的是一个方法和一个参照，不是一个可以套用的比例。