GIF to Animated WebP: The Biggest Savings
Converting 25 production GIFs to animated WebP cut the median file size by 51%. All 25 kept their frame count and timing. This post covers the numbers, the animation integrity check, and a libvips pitfall.
What we asked
Of the three source formats (JPEG, GIF, PNG), which one wastes the most bandwidth? GIF. A single GIF today spends roughly twice the bytes it needs to. We converted all 25 production GIFs to animated WebP and animated AVIF, then compared size and quality per file.
How we measured
Each GIF went through the same conversion pipeline the image conversion service uses. The Go image library (govips v2.15.0) handled the WebP path. The AVIF path required a separate tool (more on that in the pitfall section below). We recorded file size, SSIM (visual similarity, 0 to 1), and encode time for every conversion.
p25 / p50 / p75 are quartiles. One quarter of the images save at least the p25 value. Half save at least the p50 value.
Size reduction
| Conversion | p25 | p50 | p75 | SSIM p50 | SSIM min |
|---|---|---|---|---|---|
| GIF to WebP (q80) | 41.1% | 51.0% | 61.6% | 0.980 | 0.949 |
| GIF to AVIF (q80) | 46.6% | 54.0% | 63.3% | 0.994 | 0.979 |
Both formats cut GIF size by half at the median. AVIF compresses 3 percentage points more, but that gap is small compared to the shared gain over the original GIF.
By original file size
The savings hold across all size groups, not only in one range:
| Size group | Count | Original size range | WebP savings p50 | AVIF savings p50 |
|---|---|---|---|---|
| Small | 7 | 19.5 KB to 36.9 KB | 40.6% | 49.4% |
| Mid | 11 | 53.2 KB to 164.1 KB | 61.6% | 63.3% |
| Large | 7 | 183.6 KB to 290.9 KB | 45.6% | 50.7% |
Mid-range GIFs save the most. Small GIFs save less in percentage but are already light.
Animation integrity
Converting a GIF to another format can break the animation. Frames can merge, timing can drift, and the loop can stop. We checked all 25 conversions:
- Frame count: 25 out of 25 pass. The converted file keeps the same frame count as the source GIF.
- Frame delays: pass. The animation timing matches the original.
- Visual quality: all SSIM values are 0.949 or higher. The eye cannot tell the difference.
The animated AVIF pitfall
This section tells the story of a bug we found and fixed during the benchmark. It matters because it shows why animated WebP is safer to ship today.
Attempt 1: govips ExportAvif. The Go image library wrote a multi-page HEIF container (the file reported multiple pages). But it did not transfer the GIF frame-delay timing into the HEIF sequence. The browser showed only the first frame. The animation looked static.
Root cause: libvips ExportAvif (the heifsave operation) writes each frame as a HEIF page, but does not write the per-frame delay metadata. This is a libvips limitation, not an AVIF format limitation.
Attempt 2: ffmpeg without -fps_mode passthrough. We switched to ffmpeg. It produced 1,000 interpolated frames at 100 fps instead of the original 4 frames. The file was 2x larger than the source GIF. The first frame held for 2 seconds, then the animation played too fast. It looked broken.
Attempt 3: ffmpeg with -fps_mode passthrough. This flag tells ffmpeg to keep the original frame count and per-frame timing. It worked. All 25 GIFs converted with correct frame count, correct delays, and correct SSIM.
The takeaway: animated WebP works natively in govips (the Go wrapper for libvips). Animated AVIF needs a separate ffmpeg path with a specific flag. For a production image conversion service, that extra path is extra complexity and extra risk. This is one more reason to ship WebP first.
Encode time
Encode time (the CPU cost to convert one image) is a one-time cost at upload. Users never wait on it. But it affects how fast the conversion service processes a batch.
| Conversion | p25 | p50 | p75 |
|---|---|---|---|
| GIF to WebP | 8 ms | 45 ms | 61 ms |
| GIF to AVIF (ffmpeg) | 366 ms | 1,793 ms | 2,333 ms |
| JPEG to WebP | 5 ms | 14 ms | 23 ms |
| JPEG to AVIF | 171 ms | 340 ms | 521 ms |
| PNG to WebP | 7 ms | 9 ms | 17 ms |
| PNG to AVIF | 205 ms | 268 ms | 577 ms |
GIF to WebP takes 45 ms at the median. GIF to AVIF takes 1,793 ms. That is 40x slower. The AVIF encode time for GIF is high because it runs through the ffmpeg path (the pitfall fix above). For JPEG and PNG the gap is smaller (24x to 30x), because those use the govips path for both formats.
The encode speed difference is not a reason to reject AVIF outright. But it does mean the conversion service needs more capacity for AVIF. For a first rollout, WebP is the lighter lift.
What this means for the serving experience
GIF is where the format change has the largest impact on user experience. The same animation, 51% less data, all frames and timing preserved. The conversion path (govips) handles animated WebP natively. No special tool, no flag, no second attempt.
For the deeper comparison of WebP vs AVIF across all three source formats, see Part 02: WebP vs AVIF.
References:
- https://github.com/nicolo-ribaudo/tc39-proposal-is-usable-by-default (libvips animated AVIF limitation, verified with govips v2.15.0 + libvips 8.18.6)
- https://ffmpeg.org/ffmpeg.html#Options (ffmpeg
-fps_mode passthroughflag)
Related: Back to the Image Format Benchmark overview. For how GIF animation works as a page-strip in libvips, see libvips stores animation as a page-strip from the image processing series.