Back in the day (around 1990) I implemented a gif-like effect for terminals, which happened to be old monochrome hardware terminals on slow (9600?) RS-232 ports, attached to a venerable PDP-11.

It took several text files with ASCII "pictures" (character data only, no control codes, 80x24) as animation frames, and calculated simple per-line "diffs". Then it generated a sequence of cursor movements to only update the affected areas, skipping large parts of the picture.

That made it much faster than the naive overwriting the whole screenfuls from top, with a visible delay between parts of the screen. My version was able to run "simultaneous" small animations quickly at distant parts of the screen, because they took very few bytes to navigate to and update.

   *
     *. 
  * o/
  -/M 
   _H_

E.g. a "juggler" like this could juggle quickly, inside a mostly stationary "circus", with "flags" waving high above on top of it.

With current terminals giving you 60fps in true-color mode, it makes little sense, of course.

Not redrawing the parts of the screen that don't need to be redrawn. There's going to be a tradeoff between the amount of works the terminal has to do parsing the input stream, the amount of work the terminal has to do to redraw/update its own buffer, and the amount of work necessary in the program to compute the necessary move commands.

IIRC, ncurses does this under the hood.

I think the canonical way would be to ship this in some sort of hard-to-uninstall snap or flatpack package.