Web animation performance: keeping motion smooth on real devices

Which properties are cheap to animate?

Transform and opacity, because the compositor can apply them without recalculating layout or repainting pixels.

/* Forces layout on every frame */
.card:hover { width: 320px; top: -4px; }

/* Compositor handles it — same visual result */
.card { transition: transform 200ms ease-out; }
.card:hover { transform: translateY(-4px) scale(1.05); }

What is layout thrashing?

// Bad: read after write, in a loop — forces synchronous layout each iteration
for (const el of items) {
  el.style.height = "auto";
  const height = el.offsetHeight;  // forces layout, every time
  el.style.height = height + "px";
}

// Better: batch all reads, then all writes
const heights = items.map(el => el.offsetHeight);
items.forEach((el, i) => { el.style.height = heights[i] + "px"; });

Reading a geometry property forces the browser to flush pending style changes and recalculate layout. Doing that inside a loop turns one layout pass into hundreds, which is why some animations are fine with ten items and unusable with a hundred.

How much animation is too much?

• Animating dozens of elements simultaneously will drop frames regardless of which properties you use.
• Scroll-driven animation is the most common cause of jank — every scroll event competing for the main thread.
• Long-running background animation drains battery and keeps the compositor busy on every frame.
• will-change promotes an element to its own layer; used liberally it exhausts memory and makes things worse.
• If an animation exists only because it looked good in a design tool, question whether it earns its cost.

How do you respect reduced motion?

@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;
  }
}

Some users experience nausea or vestibular symptoms from parallax and large motion. The preference is set at the operating system level, and honouring it is a WCAG requirement rather than a nicety.

• Reduce does not have to mean remove — a fade instead of a slide is often the right substitute.
• Parallax, auto-playing carousels and large scale transitions are the highest-risk patterns.
• Check the preference in JavaScript too, for animations driven by code rather than CSS.
• It doubles as a performance escape hatch on low-end devices, which frequently have it enabled.

How do you debug a stuttering animation?

1. 1Record a performance profile in DevTools while the animation runs.
2. 2Look for long tasks and purple layout blocks in the flame chart — those are the cost.
3. 3Enable paint flashing to see what is repainting; a whole-screen flash on a small hover is the problem.
4. 4Check the layer count. Too many promoted layers costs memory and can slow compositing.
5. 5Throttle the CPU 4x and repeat. If it is smooth throttled, it is smooth on real hardware.