Core CSS Animation Fundamentals

Modern web interfaces demand fluid, accessible, and performant motion. This page maps browser rendering mechanics to declarative motion design, covering the four architectural layers every production CSS animation system must address: choosing between CSS transitions and animations, building precise keyframe timelines, selecting timing functions that feel natural, and keeping execution on the compositor thread via hardware-accelerated properties. Each section below connects directly to a dedicated deep-dive page.

---

Browser rendering pipeline overview

Every CSS animation decision ultimately affects one of four rendering phases. The table below maps each topic on this page to the phase it primarily targets — use it as a quick orientation before diving in.

---

Rendering pipeline diagram

The SVG below shows how a CSS animation moves through the browser’s rendering pipeline from style resolution to the compositor thread. Understanding where each phase hands off is essential for knowing which optimisations have real effect.

---

Declarative motion primitives: transitions vs animations

CSS gives you two distinct motion primitives, and choosing the right one for a given interaction determines both code clarity and rendering predictability. CSS transitions are reactive: they fire automatically when a targeted property changes, interpolating from the old to the new computed value. A nav link that changes background-color on :hover is a perfect transition candidate — the browser handles the interpolation without you defining a timeline.

@keyframes animations operate on a self-contained, declared timeline. They play independently of property triggers, can loop, reverse, and hold their end state with animation-fill-mode. When you need a loading spinner, a multi-step entrance sequence, or motion that runs without a preceding state change, an explicit @keyframes block is the right tool. The dedicated guide when-to-use-transition-vs-keyframe-animation covers the decision criteria in depth.

A common mistake is applying @keyframes to toggle states that a transition would handle with less code and cleaner reset behaviour. Conversely, trying to drive a multi-step choreography through stacked :hover and :focus pseudo-class transitions creates fragile, hard-to-maintain CSS. Matching the primitive to the problem keeps your cascade clean and avoids redundant style recalculations.

/* Transition: implicit, reactive — triggered by class toggle */
.button {
  background-color: hsl(260 70% 40%);
  transition: background-color 200ms ease-out;
}
.button:hover {
  background-color: hsl(260 70% 55%);
}

/* Animation: explicit, self-driven timeline */
.spinner {
  animation: spin 800ms linear infinite;
}

@keyframes spin {
  to { transform: rotate(360deg); }
}

@media (prefers-reduced-motion: reduce) {
  .button { transition: none; }
  .spinner { animation: none; }
}

Rendering Impact: background-color — paint. transform: rotate() — composite only.

---

Physics-based easing and timing functions

Perceived motion quality depends more on how a property value changes over time than on how far it travels. Timing functions and easing curves map the animation’s progress fraction to an output value fraction, controlling perceived acceleration and deceleration.

The browser provides keyword shortcuts (ease, ease-in, ease-out, ease-in-out, linear) that cover common scenarios, but they are fixed approximations. cubic-bezier(x1, y1, x2, y2) gives you full control over a two-handle Bézier curve. The P1 handle controls initial acceleration; P2 controls the approach to rest. A value of cubic-bezier(0.2, 0, 0.4, 1) produces a fast start with a smooth deceleration — suitable for elements entering the viewport. For elements leaving, invert the emphasis: cubic-bezier(0.4, 0, 1, 0.6).

Step functions (steps(n, start|end)) serve a completely different purpose — they produce discrete jumps rather than smooth interpolation. They are the correct tool for sprite-sheet animation where you want pixel-perfect frame advances rather than blending between frames. Perceptual research places the threshold for “instantaneous” interaction feedback at around 100ms; UI state confirmations (checkbox toggle, button press) should target that window. Longer, structural transitions (modal entry, page hero) can extend to 300–400ms before users perceive them as slow.

/* Natural entrance: fast start, cushioned landing */
.card--enter {
  animation: card-in 350ms cubic-bezier(0.2, 0, 0.4, 1) both;
}

@keyframes card-in {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

/* Sprite animation using step function */
.icon-sprite {
  animation: sprite-walk 600ms steps(8, end) infinite;
}

@keyframes sprite-walk {
  to { background-position-x: -640px; } /* 8 × 80px frames */
}

@media (prefers-reduced-motion: reduce) {
  .card--enter { animation: none; opacity: 1; transform: none; }
  .icon-sprite { animation: none; }
}

Rendering Impact: opacity + transform — composite only. background-position — paint.

---

Keyframe architecture and state mapping

@keyframes blocks are declarative state machines. Each percentage stop (or the from/to shortcuts) defines a target property set that the browser interpolates toward at the corresponding point in the animation’s progress. Keyframe architecture and state mapping covers how to structure these timelines so they survive responsive scaling, CSS custom property injection, and dynamic content.

The key architectural discipline is restricting keyframe declarations to compositing-safe properties wherever possible. A keyframe that changes height or top at every stop forces a layout recalculation per frame — at 60fps that is 60 layout passes per second per animated element. Replacing a height animation with a scaleY() transform achieves a visually equivalent effect at zero layout cost.

CSS custom properties unlock dynamic, data-driven keyframes. By reading a --distance variable inside the @keyframes block, the same animation rule can produce different travel distances for different component instances. Combining this with animation-composition: add (a newer property) allows multiple animations to layer without overwriting each other’s output. For complex multi-component choreography, the mapping UI states to CSS custom properties page shows how to wire component state into the animation system declaratively.

/* Dynamic keyframe using custom property */
.notification {
  --slide-distance: -60px;
  animation: notify-in 300ms cubic-bezier(0.2, 0, 0.4, 1) both;
}

/* Compact variant travels half the distance */
.notification--compact {
  --slide-distance: -32px;
}

@keyframes notify-in {
  from {
    opacity: 0;
    transform: translateY(var(--slide-distance));
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

@media (prefers-reduced-motion: reduce) {
  .notification,
  .notification--compact {
    animation: none;
    opacity: 1;
    transform: none;
  }
}

Rendering Impact: opacity + transform — composite only.

---

Compositor-first execution and hardware acceleration

The single highest-leverage decision in CSS animation architecture is keeping work on the compositor thread. The main thread handles JavaScript execution, style recalculation, and layout — it is already under pressure in any non-trivial page. Handing animation work to the compositor thread means the GPU can advance animation frames independently, even while the main thread is processing a large JavaScript task.

Only two CSS properties are guaranteed to execute on the compositor thread in all major browsers: transform and opacity. Every other property — color, background, border-radius, box-shadow, filter — triggers at minimum a paint operation, and many trigger a full layout recalculation. The hardware-accelerated properties page provides a complete reference with compositing tier classifications. For a deeper audit workflow, avoiding layout thrashing in CSS animations walks through DevTools flamechart analysis.

will-change is a promotion hint, not a performance switch. Setting will-change: transform on an element tells the browser it should prepare a dedicated GPU layer ahead of the animation starting. This eliminates the one-frame promotion cost when the animation begins, which matters most for elements that animate in response to fast user gestures. However, each promoted layer consumes VRAM. Setting will-change on more than a handful of simultaneous elements, or leaving it set when the animation is not active, causes layer explosion — a condition where GPU memory pressure degrades rendering worse than the layout thrashing you were trying to avoid.

/* GPU promotion scoped to the active animation period */
.panel {
  /* No will-change at rest — saves VRAM */
}

.panel--animating {
  will-change: transform, opacity;
  animation: panel-slide 400ms cubic-bezier(0.2, 0, 0.4, 1) forwards;
}

@keyframes panel-slide {
  from {
    transform: translateX(100%);
    opacity: 0;
  }
  to {
    transform: translateX(0);
    opacity: 1;
  }
}

@media (prefers-reduced-motion: reduce) {
  .panel--animating {
    will-change: auto;
    animation: none;
    transform: none;
    opacity: 1;
  }
}

Rendering Impact: transform + opacity — composite only. will-change — promotes element to a new GPU layer.

---

Animation state management and event handling

Declarative CSS animations are stateless from the browser’s perspective — they run their timeline and stop. Complex interactive UIs require an explicit state layer to coordinate pauses, reversals, conditional entry/exit sequences, and synchronisation with application data. Animation state management covers the architectural patterns for bridging CSS timelines with JavaScript application state.

The Web Animations API (WAAPI) is the specification-level bridge. element.getAnimations() returns all running Animation objects on an element, each with a playState, a currentTime you can set programmatically, and a finished Promise that resolves on completion. This lets you write conditional logic against animation lifecycle without polling or arbitrary setTimeout delays.

Class-toggle patterns remain the most maintainable approach for UI state transitions. A well-designed class scheme applies a single class (.is-open, .has-loaded, .is-exiting) and delegates the full interpolation to CSS, with JavaScript only responsible for toggling the class at the right moment. This keeps the rendering engine in control of frame timing. The syncing CSS animations with JavaScript event loops page covers the timing nuances of animationstart, animationend, and animationiteration events.

/* State machine via class toggle */
.drawer {
  transform: translateX(-100%);
  opacity: 0;
  transition: transform 300ms cubic-bezier(0.2, 0, 0.4, 1),
              opacity 200ms ease;
}

.drawer.is-open {
  transform: translateX(0);
  opacity: 1;
}

.drawer.is-exiting {
  transform: translateX(-100%);
  opacity: 0;
  transition: transform 200ms cubic-bezier(0.4, 0, 1, 0.6),
              opacity 150ms ease-in;
}

@media (prefers-reduced-motion: reduce) {
  .drawer,
  .drawer.is-open,
  .drawer.is-exiting {
    transition: none;
    opacity: 1;
    transform: none;
  }
}

Rendering Impact: transform + opacity — composite only.

---

Performance budget summary

---

Accessibility gate: prefers-reduced-motion strategy

prefers-reduced-motion: reduce is a user-level operating system preference that signals vestibular sensitivity, motion-triggered conditions, or simply a preference for minimal movement. Ignoring it excludes a meaningful portion of your audience and may trigger genuine medical symptoms.

The correct strategy is a two-layer approach. The global rule below provides a blanket reset that catches anything not explicitly overridden. Component-level overrides then restore only the specific transitions or animations that are functional rather than decorative — for example, a focus-ring pulse that communicates interactive state should still fire, but as an opacity change rather than a spatial movement.

/* Layer 1: global cascade reset */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

/* Layer 2: restore functional motion (opacity only — no movement) */
@media (prefers-reduced-motion: reduce) {
  .focus-ring--pulse {
    animation: focus-pulse-reduced 1.2s ease infinite;
  }
  @keyframes focus-pulse-reduced {
    0%, 100% { opacity: 1; }
    50%       { opacity: 0.5; }
  }
}

Test the implementation in Chrome by opening DevTools → Rendering tab → enable “Emulate CSS media feature prefers-reduced-motion”. Verify that every animation either stops or reduces to a functional-only opacity change.

---

Common pitfalls

• Animating width, height, top, or left triggers a full layout recalculation every frame. Replace with transform: scaleX(), scaleY(), or translate() equivalents that stay on the compositor thread.
• Setting will-change globally or at rest causes layer explosion. Apply it only to elements that are about to animate, and remove it via class toggle once the animation ends.
• Omitting prefers-reduced-motion fallbacks excludes users with vestibular disorders and violates WCAG 2.1 Success Criterion 2.3.3 (Animation from Interactions).
• Chaining animations without lifecycle synchronisation leads to race conditions where a second animation fires before the first reaches animationend, producing compound transform drift.
• Using linear easing for UI state transitions produces robotic motion. Even ease-out is meaningfully more natural; reserve linear for continuously looping animations (spinners, progress bars) where easing would create a perceptible jerk at the loop point.
• Querying layout properties (e.g. offsetWidth) inside rAF callbacks alongside animation triggers forces synchronous layout — the browser must resolve geometry before returning the value, stalling the main thread mid-frame.
• Overusing animation-fill-mode: forwards leaves promoted GPU layers active after animation completion, consuming VRAM indefinitely. Remove will-change and reset to the final state via a class toggle rather than relying on fill mode.

---

FAQ

Why should I avoid animating layout properties like margin or width?

Animating layout properties forces the browser to recalculate geometry and repaint affected regions on every frame, causing main-thread congestion and dropped frames. Restrict animated properties to transform and opacity for compositor-only execution, and use scaleX()/scaleY() to simulate size changes where needed.

How do I enforce a strict performance budget for CSS animations?

Limit concurrent animations, cap durations under 400ms for UI transitions, use only composite-thread properties, and audit with the Chrome DevTools Performance panel to ensure frame times stay below 16.67ms. The Layers panel shows you which elements have been promoted to GPU layers and their memory cost.

When should I use the Web Animations API instead of pure CSS?

Use WAAPI when you need dynamic timeline control, programmatic playback state, timeline scrubbing, or synchronisation with complex application state. Pure CSS remains the right choice for static, declarative UI transitions where the browser can fully manage timing without JavaScript involvement.

How does prefers-reduced-motion impact animation architecture?

It requires a fallback strategy that disables non-essential motion, reduces animation duration to near-zero, or replaces spatial movement with functional opacity changes. This must be implemented at the CSS cascade level — not as a JavaScript feature-detect toggle — so the media query fires before any paint occurs.

What is the difference between CSS transitions and CSS animations?

Transitions interpolate between two states triggered by a property change; they are implicit and reactive. Animations use @keyframes to define an explicit multi-step timeline that runs independently of property triggers. Transitions are simpler to maintain for two-state interactions; @keyframes are necessary for loops, multi-stop sequences, and motion that does not correspond to a DOM state change.

---

Related

• CSS Transitions vs Animations — decision framework and rendering mechanics for both primitives
• Timing Functions & Easing Curves — cubic-bezier mathematics, perceptual thresholds, and step functions
• Keyframe Architecture & State Mapping — timeline structure, custom properties, and animation-composition
• Hardware-Accelerated Properties — compositing tier reference and will-change strategy
• Animation State Management — WAAPI, class-toggle patterns, and lifecycle event synchronisation
• Performance Budgeting & GPU Architecture — frame budget targets, layer promotion, and GPU memory constraints