GIFs are pretty optimized files — where each "frame" can be a diff from the previous. "De-diffing", converting palette-based pixels to full 24 or 32-bit RGB could really blow up fast.
This is a given for movie formats, but at the time the animated GIF came up it was revolutionary. I think the proper phrase should be "animated GIFs can be pretty optimized, taking into account how inefficient the algorithm is, when compared with other animation algorithms of the time".
I also think there's an interpretation that applies here: When you see an animated gif, even if it's a frame that changes three pixels and nothing else, internally the renderer may be expanding it into a full movie (that is, uncompressing each resulting "frame"). This usually makes GIFs (regardless of how large or small the GIF actually is) take much more memory than common sense would tell you.
1. animation isn't technically intended by the gif format [0]:
> Although GIF was not designed as an animation medium, its ability to store multiple images in one file naturally suggested using the format to store the frames of an animation sequence. To facilitate displaying animations, the GIF89a spec added the Graphic Control Extension (GCE), which allows the images (frames) in the file to be painted with time delays, forming a video clip > > To enable an animation to loop, Netscape in the 1990s used the Application Extension block (intended to allow vendors to add application-specific information to the GIF file) to implement the Netscape Application Block (NAB).........Most browsers now recognize and support NAB, though it is not strictly part of the GIF89a specification
2. SMIL[1] is an animation alternative I'd never heard of for the browser.
[0]: https://en.wikipedia.org/wiki/GIF#Animated_GIF [1]: https://en.wikipedia.org/wiki/Synchronized_Multimedia_Integr...