Анимацию мы не разбираем на кадры
Для анимированных GIF работает отдельный путь: файл идёт в gifsicle (тот самый классический оптимизатор, собранный в WebAssembly) байтами и байтами же возвращается. Ничего не перерисовывается заново, поэтому порядок кадров, задержки и зацикливание остаются ровно такими, какими были.
Рычаги отображаются на его ключи:
- Палитра — сколько цветов оставить (
--colors). Обычно самый сильный рычаг: 256 → 64 цвета часто режет вес вдвое почти без заметной разницы. - Качество — управляемая потеря в пикселях (
--lossy). Чуть «замыливает» шум, зато кадры становятся похожими друг на друга и сжимаются лучше. - Разрешение — уменьшение стороны, как и везде, работает сильнее всего.
Замер на реальной гифке: 41 143 → 32 044 байта (−22%) только оптимизацией, и 20 236 байт (−51%) после палитры в 32 цвета — все 12 кадров на месте.
Сравнение до/после — по одному таймеру
Две гифки рядом обычно расходятся: браузер держит часы анимации на URL, а не на элементе, и превью начинает врать. Мы декодируем обе стороны в кадры и рисуем их из одного цикла отрисовки — индекс кадра берётся из общего времени. Разъехаться физически не может, так что сравнивать «до» и «после» можно честно, а не «примерно».
FAQ
Статичный GIF тоже примете?
Да, но он пойдёт обычным растровым путём — и там почти всегда выгоднее сохранить его в PNG-8 или WebP, а не оставлять в GIF.
Почему нельзя сохранить анимацию в WebP или AVIF?
Анимированные контейнеры этих форматов мы пока не пишем — честнее сказать прямо, чем молча отдать один кадр. Для анимации сейчас поддержан GIF.
Прозрачность сохранится?
Да, GIF хранит один прозрачный индекс палитры — он переживает оптимизацию.
Файлы уходят на сервер?
Нет. gifsicle работает внутри вашей вкладки.