Three levers, in order of pain
A GIF's size is colours times pixels times frames, roughly speaking, and this tool exposes exactly those three multipliers. The palette cut is where to start: GIF allows 256 colours, most animations use that headroom carelessly, and 128 colours with a well-built palette is close to indistinguishable in motion. The default pass does just this, and for many files it is all that is needed.
When it is not, scale is next. Reducing dimensions to 75 percent removes almost half the pixels; 50 percent removes three quarters. Chat windows and comment threads display GIFs small anyway, so the pixels you shed were often never seen. The frame-rate cap is the last resort because it is the most visible: 15 fps still reads as motion, 10 reads as economical.
Why the palette is rebuilt, not just truncated
Naive compressors keep the GIF's existing palette and drop entries, which posterizes whatever those entries were doing. This tool re-watches your actual frames and builds a fresh palette of the target size weighted toward the colours that matter, then re-maps every frame with ordered dithering. The result at 128 colours routinely looks better than a lazy tool's output at 256.
Knowing when the format is the problem
There is a floor under all of this: a long, high-motion GIF is expensive because GIF was never meant for that job. If the destination accepts video, converting beats compressing by an order of magnitude, and takes one click on our GIF to MP4 page. A GIF compressor earns its keep where the file must stay a GIF, which usually means forums, READMEs, documentation and anywhere else that treats animations as images. For those places, this page runs the whole job locally in your browser, shows you the cost of each lever before you commit to it, and never sends your file anywhere.