CodeKitHub工具介绍
GIF 是 1989 年的格式，每一帧都存成完整的调色板图像——这就是动图巨大的原因。压缩 GIF 就是攻击决定体积的三个因素：每帧颜色数（GIF 上限 256）、像素尺寸、帧数。
本工具解码每一帧，按需缩小，把调色板重新量化到你选的颜色预算，还可以每两帧丢一帧同时保持时间轴（动画速度不变，只是略微不那么顺滑）。全程本地运行——解码用浏览器内置引擎，编码用开源 GIF 编码器。
为什么使用它？
- 三个真实手段——减色、缩放、抽帧——各有明确取舍，组合起来通常省 60–80%。
- 抽帧保持时长：动画播放速度不变。
- 本地处理：GIF（常是带隐私内容的屏幕录制或表情包）不会上传。
- 支持批量，逐文件显示节省，免费无水印。
- 诚实降级：浏览器不支持逐帧解码时明确提示，而不是悄悄输出坏文件。
使用方法
- 把 GIF 文件拖到虚线框（编码器首次自动加载，仅一次）。
- 设置颜色数——128 通常看不出来；64 省得更多。
- 按需缩放到 75%/50%——大 GIF 最有效的一招。
- 长录屏可勾选抽帧，轻微顿挫换一半体积。
- 下载每个压缩结果；节省比例逐个显示。
示例
输入
屏幕录制.gif — 8.4 MB，480 帧输出
屏幕录制-compressed.gif — 2.1 MB（−75%），50% 缩放 + 128 色缩放是最强的杠杆：尺寸减半，每帧像素只剩四分之一。
常见使用场景
- 给GitHub README压缩屏幕录制GIF——README附件通常有大小限制，原始录制很容易超过。
- 在有严格文件大小限制的聊天软件或论坛发表情包/反应GIF前先压缩。
- 给落地页压缩产品演示GIF——每多一兆都会拖慢访客的加载速度。
- 给Slack或Discord准备教程GIF——这些平台的附件大小上限通常远低于未压缩录屏的体积。
该先动哪个手段
三个手段的效果不对等，知道先后顺序能省时间：缩放（像素尺寸）效果遥遥领先，因为宽高各减半会去掉每一帧75%的像素——这个节省在所有帧上累加，不只是一帧的事。抽帧对长录屏是第二大手段，10秒30帧的GIF有300帧里很多是近乎重复的冗余画面，降到15帧几乎看不出明显影响。减色是真实有效的，但对典型的照片类或屏幕录制内容来说是三者里最小的一个——它对本来就是简单纯色图形的GIF效果最明显，那种GIF本来就用不上很大的调色板。
常见问题
哪个设置最省体积？
缩放，遥遥领先——50% 缩放让每一帧的像素减少 75%。其次是抽帧（约省一半），然后是减色。特别大的 GIF 三招齐上。
抽帧会让动画变快吗？
不会——保留帧的延时会加倍，总时长完全一致。只是动作稍微不那么顺滑，屏幕录制类内容基本察觉不到。
为什么提示浏览器无法解码？
逐帧解码依赖 ImageDecoder API，Chrome、Edge 和新版 Firefox 支持。老浏览器和部分 Safari 版本没有——工具会诚实告知，而不是输出损坏的文件。
2026年了还该用 GIF 吗？
说实话：多数场景不该。GIF 把每一帧都存成完整的 256 色调色板图像，没有任何帧间运动压缩，所以 H.264 这类视频编码器处理同样的片段，转成 MP4/WebM 体积小 5–10 倍、画质更好、所有平台都能播。只有当目标平台只接受 GIF（或必须以图片形式自动播放）时才压缩 GIF；只要格式由你决定，就转 MP4/WebM。GIF 仍然赢在"无控件自动播放"的场合（README 文件、部分聊天工具）。必须用 GIF 时，本工具让它体积可以接受。
压缩时 GIF 会被上传吗？
不会——解码和重编码完全在浏览器里进行。带敏感内容的屏幕录制留在你自己的电脑上。
转换成 MP4 会比压缩 GIF 更小吗？
几乎总是如此，而且差距很大。GIF 将每一帧都存储为完整的 256 色调色板图像，没有帧间运动压缩，因此像 H.264 这样的视频编码器通常能为同一段片段生成小几倍的文件。当目标只接受 GIF（或必须以图片形式自动播放）时才压缩 GIF；只要你能自行选择格式，就转换成 MP4/WebM。