GIF stores every frame on a 256-colour palette, so as soon as the frame count grows the file explodes. There are only three levers that really work: fewer colours, smaller frames, fewer frames per second.
1. Fewer colours: best value for effort
Most GIFs use far fewer than 256 colours in practice. Dropping to 128 is usually invisible and cuts 30-50% of the size; dropping to 64 starts to show banding but works well for flat-background icon animations. GIF compression exposes the colour count directly, so you do not need to understand palettes.
2. Smaller dimensions: size falls with the square
Scale width and height to 70% and you keep 49% of the pixels, which roughly halves the file. A chat sticker at 320 px wide is plenty; there is no reason to keep 800 px. Resizing is more visible than reducing colours, but it is the most effective way to make a file sendable.
3. Fewer frames: the most brutal lever
Going from 30 fps to 10 fps removes two thirds of the frames and about two thirds of the size. The cost is choppy motion. The test is whether the camera moves: small in-place motion (expressions, shaking) survives frame dropping, panning shots do not.
4. A parameter set you can copy
Taking a 10 MB, 800x600, 25 fps GIF under 2 MB:
- Resize to 70% -> about 5 MB
- Colours 256 to 128 -> about 2.5 MB
- Frame rate to 12 fps -> about 1.2 MB
Stack all three and the quality is still usable. Doing only one of them rarely gets 10 MB down to 2 MB.
5. Split frames to diagnose
Old GIFs often carry duplicate or solid-colour frames that cost size for nothing. Export with GIF frame extraction and look: if you see long runs of identical frames, the source frame rate was padded and re-exporting is cheaper than compressing.
6. Fix it at the source
If you are generating the GIF from a video yourself, do not render a huge GIF and compress it afterwards. Export with sensible settings the first time (480 px wide, 10 fps, under 5 seconds). Converting and then compressing encodes twice, which costs quality and time.