Three levers, and what each of them costs
A gif optimizer has less to work with than you might think, and a GIF is heavy for one reason: it stores a sequence of full indexed images with a compression scheme designed in the 1980s. There is no motion prediction, so a frame that differs slightly from the last still costs nearly as much as a fresh one. That leaves exactly three things to trade.
Colours come first. Each frame draws from a palette of at most 256 entries, and cutting that to 128 or 64 shrinks the file while barely showing on flat graphics, screen recordings and line art. Scale comes second and is more predictable: halving the width quarters the pixel count. Frame rate comes last, because it is the one people notice, changing how the motion feels rather than how any single frame looks.
When to stop optimising and change format
If the source is video footage, no amount of GIF optimisation will win. Every frame of a photographic scene differs from the previous one almost everywhere, which is precisely the case GIF has no answer for and modern video codecs were built around. The same clip as an MP4 is routinely a quarter of the size and looks better, and there is a GIF to MP4 page here for exactly that.
Stay with GIF when the destination needs it: an ordinary image tag that autoplays, a chat client or forum that does not handle video inline, an email template, or software old enough that a video element is not an option.
Reading the result
The saving is printed on the row after each run, so the comparison is a number rather than an impression. Change one control at a time and press apply; the point of separate levers is that you can see which one bought the reduction and which one only cost you quality.
To optimize GIF files well, change one thing at a time and keep the version that bought the most for the least. Everything runs in your browser. Files up to 500 MB are accepted, nothing reaches a server, and the engine is fetched once and cached afterwards.