I waited five seconds for my own docs site on the subway, so I put its GIFs on a diet

My docs site has five demo animations above the fold. 269 KB total. Not much — until I opened my own site on the subway and sat there watching a blank rectangle.

I went home and compressed all five. Here's every number, including the cost.

Before

All five are screen recordings: the interface mostly holds still, a progress bar and a cursor move. Dimensions from 560×315 to 720×405, 24 to 40 frames.

What I changed

One line: palette reduction and frame differencing only. Dimensions and frame rate untouched.

That was a rule I set for myself before starting. Shrinking dimensions blurs the small text in the UI; dropping frames makes the cursor stutter. Both of those change the content, and what I wanted was the same footage taking less room.

I used ImgIng's animation workshop (imging.ai). The practical reason: these recordings show an internal console, and I'd rather not upload them anywhere. Frame splitting and re-encoding run in the browser — I kept the Network tab open through all five files and no POST request was made. Don't take my word for it; the check takes a minute.

After

All five landed on 64 colours. I didn't set that — the tool picks it from the content. Flat UI palettes don't need more, and at this footage there's nothing visible to lose.

The interesting row is deploy: it's the largest and longest of the five and not the biggest file. Its interface holds still more than any of the others, so differencing wins more. What sets your ceiling is the proportion of pixels standing still, not the resolution.

What it cost

Cost 1: the palette went from 256 to 64. Invisible on flat interfaces. If your demos have gradient backgrounds, photos, or semi-transparent overlays, 64 colours will band. Mine are pure UI, so nothing to see.

Cost 2: one more step forever. Every future demo recording now has to be compressed before it ships. I added it to the release checklist, because otherwise I would absolutely forget.

What it did not cost: dimensions, frame rate, playback timing. Original frame durations and loop settings came through intact. I checked that on purpose — if the pacing of a screen recording changes, the demo is lying about how fast the product is.

Two categories I didn't touch

The two video-derived animations in the README. Live action, gradients, every pixel changing. I tried one; the size barely moved. That material shouldn't be a GIF at all — I swapped those for a video element instead, which is a different job.

Spinners from the component library. Third-party, already optimised. I ran one 2 KB spinner through: it came out at 1.5 KB. Five hundred bytes isn't worth the changelog line.

Was it worth it

187 KB saved. Honestly, on a docs site with three-digit daily traffic, that's a number too small to brag about.

But those seconds on the subway were real. When you build alone, a lot of decisions happen this way — not calculated, just personally annoyed by something you made yourself.

The rational version: those animations are all above the fold, so they compete with first paint on a weak connection, and the work was a one-time twenty minutes. If yours sit on secondary pages or already lazy-load, push this down your list. Don't restructure anything for 187 KB.

Limits

These numbers come from my own footage, all flat-palette UI recordings. A different kind of animation gives completely different results — the same operation saved 7.9% on a gradient banner and nothing at all on full-frame noise. What you can take from this is the method and a reference point, not a ratio to apply.