Web animation: a guide to motion on the web

CSS animation versus JavaScript animation

Most interface motion should start in CSS. Transitions and keyframe animations are declarative, they run off the main thread for the properties that matter, and the browser optimizes them aggressively. A hover state, a panel sliding in, a color easing on focus: these are CSS work, and reaching for JavaScript to do them is usually adding complexity and cost for no benefit. The rule of thumb is that if a transition or a simple keyframe sequence can express the motion, CSS is the right tool.

JavaScript earns its place when the motion needs to be orchestrated, interrupted, or driven by something the browser cannot know in advance. Sequencing many elements with precise overlapping timing, animating to a value computed at runtime, springing toward a moving target, or tying motion to scroll or pointer position are all cases where a JavaScript approach or the Web Animations API gives you control that CSS cannot. The two are not rivals; a mature project uses CSS for the common cases and JavaScript for the few that genuinely need it.

Performance budgets and compositor-only properties

The single most important performance fact in web animation is that not all properties are equal. Animating transform and opacity can be handed to the compositor and run smoothly without forcing the browser to recalculate layout or repaint large areas. Animating properties like width, height, top, left, or margin forces layout work on every frame, which is expensive and janky once a few of them run at once. Knowing this distinction is most of what separates smooth motion from stuttering motion.

A practical animation budget means deciding in advance how much motion a screen can afford, then designing within it. Prefer transform and opacity. Animate the smallest area you can. Be skeptical of animating many elements at once, especially on long lists. And test on a mid-range phone rather than a fast laptop, because the laptop will hide problems that real users feel every day. Motion that looks effortless almost always reflects deliberate restraint about what is animated and how.

The principles of motion applied to UI

The animation principles developed for character animation translate surprisingly well to interfaces, with adjustments for the fact that users are waiting on the result rather than watching a film. Easing matters most: motion that starts and stops abruptly feels mechanical, while motion that accelerates and decelerates feels physical and calm. Things that are related should move together, and things that are causally linked should move in a way that shows the cause, so the user reads the relationship without thinking about it.

Timing is the other half. Interface motion has to be fast enough that it never makes the user wait, yet slow enough to be perceived and understood. Very short durations feel snappy and respectful of the user's time; longer ones are reserved for moments where the motion itself is carrying meaning, like a large transition that explains where you just went. The discipline is to keep functional motion brisk and save the expressive, slower motion for the rare moments that deserve it.

prefers-reduced-motion and accessibility

A meaningful number of people experience discomfort, dizziness, or nausea from large or unexpected motion, and some simply prefer a calmer interface. The prefers-reduced-motion media query lets them tell the system, and respecting it is not optional polish; it is a basic accessibility responsibility. When that preference is set, large parallax moves, sweeping transitions, and autoplaying motion should be reduced to something gentle or removed entirely, while essential feedback can remain in a quieter form.

Building this in is straightforward if you plan for it. Author the motion so that a reduced-motion branch is easy to provide, rather than bolting it on at the end. Crucially, reducing motion should not remove information: if an animation was the only thing communicating that something changed, the reduced version still has to communicate that change, just without the movement. Done well, the reduced-motion experience is not a degraded one; it is simply a calmer path to the same understanding.

SVG animation

SVG is uniquely suited to animation because it is resolution-independent and every part of the graphic is a real element you can target. You can animate a path drawing itself, morph one shape toward another, animate strokes and fills, and move pieces of an illustration independently, all while staying crisp at any size. For icons, logos, diagrams, and illustrative motion, SVG often gives you a quality and flexibility that raster approaches cannot match at a fraction of the file weight.

The techniques range from simple CSS transitions on SVG attributes to full timeline control with JavaScript libraries. Drawing a line by animating its stroke, revealing an illustration piece by piece, and looping a small ambient detail are all well within reach. The main caution is complexity: a very intricate SVG with many animated nodes can become a performance problem, so the same budget discipline applies. For most icon and illustration work, though, SVG animation is the cleanest tool available.

The animation library landscape

You do not always need a library, but a good one saves real time on complex work. GSAP is a long-established and widely used animation platform known for precise timeline control, broad browser handling, and a large ecosystem; it shines when you need to sequence many elements with exact, interruptible timing. The Web Animations API is built into modern browsers and gives you a native, dependency-free way to drive keyframe animations from JavaScript, which is attractive when you want control without adding weight.

Newer libraries such as Motion focus on a small, modern API and spring-based physics that feel natural with little tuning, and framework-specific animation tools bring motion into component models cleanly. The right choice depends on the project, not on fashion. Reach for a library when the orchestration is genuinely hard, prefer native tools when the need is simple, and evaluate any dependency by what it adds to your bundle and your maintenance burden. There is no single correct answer, only the one that fits the work in front of you.

Lottie for production workflows

Lottie is a format and set of players that render animations exported from professional motion-design tools as vector data the browser can play back. Its appeal is the workflow: a motion designer can craft something genuinely sophisticated in their own software, export it, and have a developer drop it into a page without rebuilding the animation by hand in code. That handoff is where a lot of time and faithfulness is usually lost, and Lottie closes much of that gap.

The trade-offs are worth knowing. A Lottie animation is only as light and performant as the source file; a complex composition with many layers and effects can be heavy to render, so the design has to be made with playback cost in mind. It is also less interactive than hand-coded motion, since it plays a pre-authored sequence rather than responding fluidly to live state, though players do expose ways to control and segment playback. For self-contained illustrative animations and onboarding moments, it is an excellent production tool.