A marketing page ships a 6 MB animated GIF above the fold. What should you serve instead, and why is the replacement so much smaller?

## Why GIF is so large GIF was designed in 1987 for small palette graphics, and animation was bolted on as a sequence of images. Three properties make it catastrophic for video-like content: 1. **256 colours per frame.** Anything photographic must be dithered down to a palette, which both looks poor and, ironically, *hurts* compression by adding pixel-level noise. 2. **Lossless LZW compression within a frame.** There is no perceptual model at all; the encoder is not permitted to discard anything the eye would not miss. 3. **No motion compensation between frames.** GIF can skip unchanged rectangular regions via frame disposal, but it has nothing resembling motion vectors. A panning shot, where nearly every pixel changes slightly, is effectively stored as a full new image per frame. So file size grows roughly with frame count times frame area, and a few seconds of real footage reaches megabytes fast. ## Why video is dramatically smaller Modern video codecs — H.264, VP9, AV1 — do exactly what GIF cannot: - **Inter-frame prediction.** After a keyframe, each frame is coded as motion-compensated differences from previously decoded frames. Static background costs almost nothing; only what moved is described. - **Lossy transform coding.** Residuals are transformed and quantised, discarding detail below the perceptual threshold, the same principle photographic codecs use. - **Full colour.** No palette, no dithering noise. Combined, these routinely give an order of magnitude or more reduction against the same animation as GIF, at better visual quality. The saving grows with the number of frames and the amount of motion; a two-frame blink loop will not show a tenfold win because fixed container and keyframe costs dominate. ## The replacement options, ranked **1. A muted, looping, inline video.** This is the default answer, and it is the reason browsers made muted inline playback viable at all — it is the intended GIF replacement. You get the smallest bytes and real playback control. Practical points: it must be muted and marked to play inline or mobile browsers will refuse to start it; ship a widely decodable baseline such as H.264 in MP4, optionally alongside a smaller modern encode; and treat it as media, not decoration, so it does not fight the rest of the page for bandwidth. **2. Animated WebP.** When the constraint is that the thing must remain an image element — an existing component, a CMS field that only accepts images, markup you do not control — animated WebP is the pragmatic choice. It supports inter-frame methods and lossy coding, so it is far smaller than GIF, though generally still larger than a real video encode. Support is broad across evergreen browsers. **3. Animated AVIF.** Usually smaller again, but support for the *animated* variant has been less consistent than for still AVIF, so verify current behaviour on your target browsers before depending on it rather than assuming it follows still-image support. **4. APNG.** Lossless with full alpha and broadly supported, which makes it useful for short, flat, transparent animations such as a spinner. For anything photographic it is large, because lossless plus photographic content is the same trap PNG has for stills. **5. Not a bitmap at all.** A large share of animated GIFs in production are interface motion — a loading indicator, an arrow sliding, a chart drawing itself. CSS animation or animated SVG expresses those in a few hundred bytes, scales to any density, and stays crisp. Ask this question before you optimise the GIF. ## Choosing between them The decision is mostly about what the surrounding page needs: - Need the smallest possible bytes, and can accept media element semantics? Video. - Need it to behave exactly like an image — the same sizing, the same simple markup, the same handling as every other picture on the page? Animated WebP. - Is it flat vector-ish motion? CSS or SVG, and skip the bitmap entirely. Whatever you pick, remember an autoplaying loop is not free after download either: it keeps decoding and compositing while it is on screen, which costs battery and main-thread time on weak devices. Keep loops short, size them correctly, and respect users who have asked for reduced motion. ## Watch for the re-encode trap If all you have is the GIF, re-encoding it to video recovers the size but not the quality — the palette reduction and dithering already happened and are baked in. Go back to the original capture or export whenever you can; a video encoded from a dithered GIF spends bits describing the dither pattern.