MOTION — TIMING.

//What library to use#

CSS transitions for state changes — hover, focus, open and closed. They're declarative, the browser can often run them off the main thread, and they cost nothing to ship. GSAP when a sequence needs orchestration, because a timeline you can scrub, reverse and label is worth real money on a project with several people maintaining it. A hand-written requestAnimationFrame loop when I need a value computed per frame from scroll position or pointer velocity.

This site uses the third option throughout: a single loop that reads layout, then writes, in that order. Interleaving reads and writes forces synchronous layout repeatedly and is the most common cause of animation that stutters for no visible reason.

//Timing is the actual craft#

Two hundred milliseconds for something small and local. Three to five hundred when an element travels or changes size meaningfully. Ease-out for things entering, because they should decelerate into place; ease-in for things leaving. Anything over six hundred milliseconds on a frequently repeated interaction becomes an obstacle by the twentieth use, no matter how pleasant it felt in review.

The test I apply: if the motion were removed, would the interface be harder to understand? If yes, it's doing work. If no, it's decoration, and decoration has a cost paid by everyone who uses the thing daily.

//Reduced motion#

A designed alternative, not a switch that disables everything. Usually that means instant state changes plus a short opacity fade, keeping the sense of change without movement. Building it last is how it ends up feeling like a punishment.

Two notes go further than this page does: motion that means something, on when an animation earns its place, and accessible motion, on building a reduced-motion variant worth shipping.