2026-10-28
A GIF that takes nine seconds to load is a GIF most people never watch. Compress gif files and the wait shrinks, but the obvious ways of doing it wreck the reason you picked the format in the first place: the animation. Dropped frames, smeared subtitles, banding across gradients, all of it comes from pushing too hard. Here is how the size is actually calculated, which four settings move it, and when you should stop using GIF at all.
Every frame in a GIF is an indexed color image with a palette of up to 256 colors. Size is roughly frames multiplied by dimensions multiplied by palette depth. Cut any one of those three and the file shrinks; cut the wrong one and it looks bad.
Biggest win, most predictable side effects. A 1200 pixel wide screen recording scaled to 600 looks identical in a chat window or a document, and it removes three quarters of the pixels. If there are subtitles, stay above 480 wide or the text goes soft.
Most frames in a screen recording are nearly identical. Going from 30 fps to 12 removes about six in ten frames and the motion still reads as continuous. The exception is fast scrolling or animated transitions, which start to stutter below 20 fps.
256 colors is a ceiling, not a default. Down to 64 barely affects UI screenshots, terminal demos and flat illustrations. Footage and gradients band at 64 colors, so keep those at 128 or 256.
Dithering fakes intermediate colors with a dot pattern. Turning it off gives you a smaller file with less noise, and the trade is hard edges in gradients. On interface captures, dithering off usually looks cleaner.
Drop the file in, adjust the three settings above, take the result, and nothing gets uploaded. For a folder of dozens, gifsicle on the command line fits better: gifsicle --lossy=80 --colors 64 -O3 in.gif -o out.gif. The lossy flag discards some color detail and takes roughly another third off the top.
The format trade offs are laid out in /blog/lossy-vs-lossless-compression. For a workflow that handles dozens of files at once, /blog/batch-compress-images-multiple covers it, and vector icons work completely differently, which /blog/compress-svg-without-breaking explains.
On a file exported straight from a screen recorder, cutting dimensions and frame rate together usually removes 60 to 80 percent. An already optimized file has maybe 10 to 20 percent left before the quality cost becomes obvious.
It depends on which setting you touch. Dimensions and frame rate leave each frame untouched. Reducing the palette or enabling lossy mode discards real color information, and gradients and photographic content show it first.
Usually because several large GIFs load at once, or one sits above the fold. Swap the hero slot for video and lazy load the rest, since file size is not the only variable.
Choose lossy GIF when the file has to play inside an email, a document or an older system. Choose MP4 or WebM for long recordings on your own site, where the same content costs an order of magnitude less.