GIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.
I disagree. The height of a DOM element is much more expensive to recompute as this article shows than a single element which gets frames swapped out with static images. The latter can be guaranteed to never impact any other part of the document. The end result of either is that the pixels in the animated area need to be recomputed, and end result which will be the same for both, but a GIF will have no further impact on anything else whereas resizing DOM elements has side effects that have to be constantly updated and checked for which scale with the number of sprites you're animating (unlike the GIF bitmap which is gonna be 'flat rate').
Likewise, for a tiny animation, having the frames of the GIF in memory and blitting them onto the screen in sequence sounds like orders of magnitude less CPU/GPU than performing all the ridiculous math-based transforms over and over again.
The Tumblr example is not instructive here because those were frequently many many frames, very colorful (often photos), and/or large in dimensions, taking up a ton of memory which was probably the main problem causing our browsers to choke. This would be none of those things.
Likewise, for a tiny animation, having the frames of the GIF in memory and blitting them onto the screen in sequence sounds like orders of magnitude less CPU/GPU than performing all the ridiculous math-based transforms over and over again.
The Tumblr example is not instructive here because those were frequently many many frames, very colorful (often photos), and/or large in dimensions, taking up a ton of memory which was probably the main problem causing our browsers to choke. This would be none of those things.