How to animate an interface without slowing it down

To animate an interface without slowing it down, keep feedback immediate, use short transitions with easing that suits the movement, and favour transform and opacity where they fit. I treat reduced motion as a behaviour contract: remove unnecessary movement without losing information or delaying interaction, then check the result on a modest device.

Choose which interface changes need animation

I start with the change in state, not the animation library. A drawer opening can explain where its contents came from. An item moving after a sort can preserve its identity. A button bouncing after every click usually explains nothing. My first test is whether removing the movement makes the interaction harder to understand. If nothing is lost, I leave it out.

I separate acknowledgement from transition. A pressed state should appear immediately, even if opening the next view takes longer. I wouldn't wait for a decorative sequence before showing validation feedback or starting a request. Animation can describe work already happening; it shouldn't become another dependency that the user has to wait through.

Material Design's motion guidance gives me a useful framework: movement can communicate relationships and direct attention. I turn that into a concrete rule for each component, such as keeping an expanding control visually connected to the content it reveals. I also specify interruption. If someone closes a drawer halfway through opening it, the motion should reverse from its current position rather than finish a lap first.

Set animation duration by distance and frequency

I use duration ranges as starting points, not universal ui animation guidelines. For a small state change, I'd begin around 100 to 160 milliseconds. For a menu or compact panel, I'd try 160 to 240 milliseconds. A larger spatial transition might need 240 to 320 milliseconds. These are working defaults I would test, not values I'm attributing to Material Design.

Distance changes the decision. Moving something 12 pixels in 300 milliseconds can feel sticky; moving it across the viewport in 100 milliseconds can be difficult to follow. Material Design relates timing to factors including travel distance and the size of the element. I also consider frequency. A transition encountered forty times during a task deserves stricter scrutiny than an occasional introductory effect.

I usually make dismissal shorter than arrival because there's less new information to inspect. More importantly, I don't make the next action wait for dismissal. I keep timing values in shared motion tokens rather than scattering arbitrary numbers through components. Three or four named durations are enough to start. I add another only when a real interaction exposes a gap.

Choose easing for entrances, exits and state changes

I choose easing after duration. An entering element generally benefits from deceleration: it covers ground early, then settles where it needs to be read. An exiting element can accelerate away. For something moving between two visible positions, I start with acceleration followed by deceleration. This follows the distinction Material Design makes between different kinds of movement, rather than applying one curve to everything.

For a small entrance, I might test cubic-bezier(0, 0, 0.2, 1). For an exit, cubic-bezier(0.4, 0, 1, 1) is a useful comparison. I treat those as candidates, not proof that the motion is right. I watch the transition at its actual size, beside the content it affects. A curve preview cannot tell me whether a menu feels reluctant to open.

I reserve linear timing for cases where constant progress is meaningful, such as a determinate indicator tied to elapsed time. I avoid spring overshoot on dense controls unless it serves a clear purpose. Springs also need interruption and settling rules. A pleasant first click isn't enough if repeated clicks leave the component wobbling or chasing an outdated target.

Animate transform and opacity without expensive rendering

Duration controls perceived pace; rendering cost controls whether frames arrive consistently. Following web.dev's animation guidance, I favour transform and opacity when they express the intended change. These properties can avoid repeated layout and paint work. Animating width, height, top or left can require more work in the rendering pipeline, although the actual cost depends on the page and implementation.

This isn't a rule to fake every layout change with a scale transform. Scaling a card can distort its text, and translating it doesn't move neighbouring content out of the way. For an accordion, I'd first ask whether the surrounding layout needs to animate at all. An immediate layout update with a restrained content reveal may be the better trade-off. If height animation is necessary, I measure it with realistic content.

I don't assume a transform is cheap just because its property name looks right. Large layers, blurred effects and substantial image content can still make movement expensive. I use browser performance tools to inspect layout, paint and compositing during the interaction. I also avoid adding will-change to every component. As web.dev explains, preparation has costs; extra layers can consume memory without delivering a useful improvement.

Implement prefers-reduced-motion as a behaviour contract

I define the reduced-motion version when I define the default version. The contract is simple: the same information, actions and final state must remain available without unnecessary movement. A drawer can appear directly in its open position. A reordering operation can update immediately and retain a static highlight on the moved item. Neither interaction needs a sweeping transition to remain understandable.

On the web, I use the prefers-reduced-motion media query described by web.dev. I prefer a static baseline and add non-essential movement under prefers-reduced-motion: no-preference. Scripted animation needs the equivalent check through matchMedia, including handling preference changes while the page is open. I remove parallax, large translations and zoom effects rather than merely making them faster. A quick zoom is still a zoom.

I don't apply a blanket near-zero duration and assume the job is done. Behaviour tied to animationend or transitionend can fail when an animation no longer runs. Focus placement, state updates and removal of dismissed elements need a reliable path that doesn't depend on decorative motion completing. If I retain a brief opacity change, I assess it separately. Reduced motion isn't permission to replace every movement with a flash.

Test frame timing, repeated input and reduced motion

I test the interaction under load, not just on an empty component page. At 60 hertz, a frame interval is roughly 16.7 milliseconds; at 120 hertz, it's roughly 8.3 milliseconds. That's time for the browser's overall work, not an allowance entirely available to my animation. I record the interaction with representative images, text and background activity, then look for dropped frames and main-thread tasks that coincide with stuttering.

I check repeated clicks, rapid opening and closing, keyboard operation and a change of viewport size mid-transition. I want to know whether focus lands somewhere usable, whether an invisible element still intercepts input, and whether visual and application states can disagree. For an exiting panel that remains mounted, I specify when it stops accepting interaction instead of letting opacity decide accidentally.

I then repeat the task with reduced motion enabled and on a modest physical device where possible. Processor throttling helps expose problems, but it doesn't reproduce every device constraint. I measure input-to-feedback delay, transition consistency and completion of the underlying task. If the motion causes stalls or makes repeated work slower, I remove effects before polishing curves. A cleaner animation isn't necessarily a more useful interaction.

Questions people ask

How long should interface animations last?

I start around 100 to 240 milliseconds for small, frequent interactions and test longer durations for larger movements. Distance, frequency and how much new information appears matter more than choosing one duration for the whole product.

Which animation properties perform best?

I usually start with transform and opacity because they can avoid repeated layout and paint work. They aren't a performance guarantee, so I check the actual interaction rather than trusting the property alone.

Should reduced motion disable all animations?

I remove non-essential spatial movement first and assess any remaining effects individually. The replacement must preserve feedback and meaning, and completing an action must never depend on an animation running.

Are stylesheet animations faster than JavaScript animations?

I don't choose based on that distinction alone. Rendering cost, main-thread work and the animation mechanism all matter. I use stylesheets for straightforward state transitions and script when coordination requires it, then measure either implementation.

Where I checked my thinking

• Material Design: Motion overview
• web.dev: How to create high-performance animations
• web.dev: prefers-reduced-motion