Five ways to put motion on a screen

Five ways to put motion on a screen, and they are not interchangeable

Before any of the format detail, there is a decision to make, and getting it wrong costs weeks. The five options, and the question each one answers:

1. Code: CSS, the Web Animations API, or a library. The motion is generated at runtime from values. Infinitely adjustable, scales to any size, costs nothing to download, and requires a developer for every change.
2. Vector data: Lottie, SVG, Rive. The motion is authored in a design tool and exported as a file the runtime plays back. Scales without loss, small, and can be swapped without a code change.
3. Raster frames: sprite sheet, animated WebP, APNG, GIF. Every frame is stored as pixels. Handles anything you can draw, including textures and photographic content, at the cost of size and memory.
4. Video. The same as raster frames but with interframe compression, which is an enormous saving. Handles photographic and filmed content. Weak at transparency, awkward to control precisely.
5. A real-time renderer: Canvas, WebGL, a game engine. Anything is possible and everything is your problem.

The three questions that decide it

Does the motion need to respond to state? If it must pause at 40 per cent, reverse, branch depending on whether the user is signed in, or track a scroll position, you need code, Rive, or Lottie with segment control. A video or an animated image plays from start to finish and takes no instruction beyond play and stop. This is the question that eliminates the most options and is usually asked last.

Is the content vector or photographic? A logo, an icon, a character drawn in flat shapes: vector. Anything filmed, anything with a photographic texture, anything with a complex gradient mesh or a blur-heavy effect: raster or video. Trying to force photographic content into a vector format produces a file with thousands of paths that is larger and slower than the video would have been.

How many times will it change? A hero animation that marketing will revise monthly should be a file a designer can replace. A button press state that will never change should be six lines of CSS. The cost of a format is not only bytes; it is who can edit it and what they need in order to ship the change.

The sizes, roughly

For a three-second 512×512 animation of a simple illustrated scene, the orders of magnitude are consistent enough to plan with:

• Lottie JSON: 10 to 60KB, often smaller gzipped than a single frame as PNG.
• SVG with CSS: 5 to 40KB for simple shapes.
• MP4 (H.264): 100 to 400KB.
• Animated WebP: 300KB to 1.5MB.
• APNG: 1 to 4MB.
• GIF: 2 to 6MB, and it will look worse than all of the above.

The interesting gap is between the video and the raster-frame formats. It is not a small optimisation; it is a factor of five to twenty, and the reason is covered in the lesson on GIF.

The runtime costs nobody budgets for

Download size is the number everybody checks. Two others matter more on a weak device.

Decoded memory. A raster animation has to exist in memory as uncompressed pixels while it plays. A 24-frame 500×500 sprite sheet is 24 × 500 × 500 × 4 bytes (about 24MB) regardless of the fact that the PNG on disk was 300KB. On a phone with a handful of these, you are the reason the browser tab reloads.

Per-frame CPU. A Lottie file with 600 shape layers is small to download and expensive to render, because the player is rebuilding vector geometry every frame. The SVG renderer in lottie-web creates a DOM node per shape; at a few hundred nodes, animating them 60 times a second is real main-thread work. The canvas renderer is usually faster for complex files and loses crisp scaling.

A useful check: if the file is under 50KB and still stutters, the problem is shape count, not bytes.

A decision path that works

• Two states, one element, no branching → CSS transition.
• A loop or a multi-step sequence in code, still simple shapes → CSS keyframes or the Web Animations API.
• An illustrated animation a designer owns and will revise → Lottie.
• The same, but it must respond to hover, drag, or application state → Rive, or Lottie with segment playback.
• A drawn line that writes itself on, or an icon that morphs → SVG, with stroke-dashoffset or a path interpolation.
• Filmed or photographic content → video, with the MP4 and WebM pair.
• Filmed content that must sit over an arbitrary background → alpha video, and read the transparency lesson before promising it.
• Fewer than about twenty frames of hand-drawn raster art → sprite sheet with steps().
• None of the above → Canvas or WebGL, and budget accordingly.

The free path

Every format here has a free authoring route. Glaxnimate authors and exports Lottie and SVG, open source, runs on a laptop with no GPU. Inkscape draws SVG and its output can be animated with CSS. Blender exports frame sequences for sprite sheets and renders video with alpha. ffmpeg converts between every raster and video format discussed. Krita does frame-by-frame animation and exports sequences. After Effects and Rive are named in job adverts and worth naming in a portfolio; nothing in this module requires either.

The limitation

There is no format that is small, scalable, photographic, interactive and universally supported. Every choice here trades one of those away, and most arguments about formats are two people optimising different corners of that trade without saying which one they are defending. Write down which of the three questions above your project answers “yes” to before the argument starts, and most format debates end in a minute.