Animation Performance Patterns

Smooth animation comes down to one rule: do as little per-frame work as possible, and keep that work off the main thread. This topic covers the compositor-only properties (transform and opacity), the Web Animations API, requestAnimationFrame timing, how to avoid triggering layout or paint on every frame, and how to diagnose jank. This is part of Compositing and GPU Acceleration.

At 60Hz you have 16.6ms per frame, and the browser needs part of that for its own compositing work, so realistically an animation tick should finish in a few milliseconds. Animating a geometric property like left or width spends that budget on layout and paint every frame; animating transform spends almost nothing because the compositor reuses the existing GPU texture. The whole topic is choosing the cheap path and keeping it cheap.

Compositor-Only Properties

Only two CSS properties can be animated entirely on the compositor thread: transform and opacity. Once an element is on its own layer, the compositor applies a transform by multiplying the layer’s draw matrix and applies opacity by changing a blend factor — neither requires re-running style, layout, or paint. Every other property (left, top, width, height, margin, box-shadow, background) needs at least a repaint and usually a full layout before a frame can be drawn. The reasons are detailed in Transform and Opacity Best Practices and why transform and opacity are GPU-accelerated.

// ❌ Animating width re-runs layout + paint every frame (~24ms on mid-tier)
function grow(el, p) { el.style.width = `${100 + p * 200}px` } // forces layout per frame

// ✅ Animating transform stays on the compositor (~1ms, main thread free)
function grow(el, p) { el.style.transform = `scaleX(${1 + p * 2})` } // compositor-only

The full migration from top/left/width/height to transforms, including the FLIP technique and will-change promotion, is covered in animating transforms without layout thrash.

The Web Animations API vs requestAnimationFrame

There are two ways to drive an animation. A requestAnimationFrame loop runs your JS callback before every frame — fine for physics or canvas, but the callback executes on the main thread, so a busy main thread janks it. The Web Animations API (element.animate(...)) and CSS transitions/animations, when limited to transform/opacity, are handed to the compositor and run off the main thread — they keep going even during a long task.

// ✅ Web Animations API on compositor-only props: survives main-thread jank
el.animate(
  [{ transform: 'translateX(0)' }, { transform: 'translateX(240px)' }],
  { duration: 400, easing: 'ease-out' },
) // compositor runs this without per-frame JS

// requestAnimationFrame loop: runs on the main thread, blocked by long tasks
function tick(now) {
  el.style.transform = `translateX(${progress(now)}px)`
  requestAnimationFrame(tick)
}

Reserve requestAnimationFrame for animations that genuinely need per-frame JS (and use it to batch DOM writes, never to read geometry mid-frame — that path is covered in debouncing scroll-driven layout reads).

Avoiding Layout and Paint Per Frame

The diagnostic question for any animation is: which pipeline stages run each frame? A compositor-only animation shows only Composite Layers. Any Layout, Recalculate Style, or Paint entry recurring per frame means the animation is touching a non-compositor property — or an ancestor’s geometry is reacting to the animated element.

Jank Diagnosis

[Frame] Budget: 16.6ms | Actual: 23.7ms — DROPPED
└─ Main thread
    ├─ Recalculate Style (2.0ms)
    ├─ Layout (11.4ms)     ← animating 'left' forces this every frame
    ├─ Paint (5.1ms)
    └─ Composite Layers (3.8ms)
[Frame] Budget: 16.6ms | Actual: 3.9ms — OK
└─ Compositor thread
    └─ Composite Layers (3.9ms)   ← same motion, animated via transform

The two frames produce the same on-screen motion; the first does it with layout and paint on the main thread, the second with a single compositor pass. To find these frames, record in the Performance panel and look for repeating Layout/Paint bars locked to the animation’s duration. Framework-driven re-renders add another layer of cost — how React’s concurrent rendering interacts with forced reflow is covered in react concurrent rendering vs forced reflow.

Metric Validation

// Flag frames that miss the budget during an animation
let last = performance.now()
function watch() {
  const now = performance.now()
  if (now - last > 18) console.warn(`Frame ${(now - last).toFixed(1)}ms`)
  last = now
  requestAnimationFrame(watch)
}
requestAnimationFrame(watch)

// Long Animation Frames attribute jank to a script or layout source
new PerformanceObserver((l) => {
  for (const e of l.getEntries()) console.log('LoAF', e.duration, e.scripts)
}).observe({ type: 'long-animation-frame', buffered: true })

For the source-level attribution of janky frames see tracking long animation frames, and continue to animating transforms without layout thrash and react concurrent rendering vs forced reflow for the focused techniques.

Driving Animation Off the Main Thread

The core principle of smooth animation is that the browser, not your JavaScript, should drive the frames. When you hand keyframes to the engine — via a CSS animation/transition or the Web Animations API — and they only touch transform and opacity, the compositor samples them on its own thread every vsync, independent of whatever the main thread is doing. A 180ms long task on the main thread cannot stall such an animation, because no per-frame callback of yours sits on the critical path. Contrast this with a requestAnimationFrame loop that writes element.style.transform each tick: even though it animates a compositor property, the driver is on the main thread, so the same long task that blocks script also freezes the animation. Registering the animation instead of driving it is the difference, and it is the pattern behind animating transforms without layout thrash.

The Web Animations API makes this explicit: element.animate(keyframes, options) registers the animation once and returns an Animation object that still gives you finished, cancel(), pause(), and playbackRate for control, all without a per-frame callback. For genuinely per-frame JavaScript work — a canvas particle system, a physics simulation — the equivalent move is to push the computation off the main thread with a Web Worker and OffscreenCanvas, or at minimum to break the blocking task with scheduler.yield() so animation frames can interleave. The rule generalises: keep the thing that advances the animation off the thread that also runs your application logic.

// ❌ compositor property, but driven on the main thread — a long task freezes it
function tick(now) {
  card.style.transform = `translateX(${progress(now) * 240}px)`
  requestAnimationFrame(tick)
}
// ✅ registered once, sampled by the compositor — immune to main-thread jank
card.animate(
  [{ transform: 'translateX(0)' }, { transform: 'translateX(240px)' }],
  { duration: 400, easing: 'ease-out' },
)

FLIP and Animating Layout Changes

The hardest animations are the ones that are inherently about layout — an item moving to a new position in a reordered list, a card expanding from a thumbnail. Animating the layout properties directly would force layout every frame, so the technique is FLIP: First, Last, Invert, Play. Measure the element’s start position (First), apply the end state and measure again (Last), compute the delta and apply an inverse transform so it appears not to have moved (Invert), then animate the transform back to zero (Play). The net effect is a layout change that animates entirely on the compositor, because the only thing changing per frame is a transform. The two layout reads happen once, up front, not every frame.

FLIP is powerful precisely because it converts the one class of animation that seems to require per-frame layout into a compositor-only one. The catch is the measurement step: the getBoundingClientRect() reads must be batched and must not interleave with writes, or you reintroduce the forced reflow you were trying to avoid — the same discipline from forced synchronous layouts. In component frameworks the reads belong in the pre-paint phase (useLayoutEffect in React, before nextTick in Vue), and the concurrency implications are covered in React concurrent rendering vs forced reflow. Done correctly, FLIP delivers list-reordering and shared-element transitions at full frame rate on hardware that would choke on the naive layout animation.

Diagnosing Animation Jank

When an animation stutters, the trace tells you which of the two failure modes you have. Record a Performance profile during the animation and read the two tracks: if Composite Layers runs on the Compositor track with the Main track idle, the animation is on the fast path and any jank is coming from elsewhere. If instead you see Recalculate Style, Layout, or Paint firing on the Main track every frame, the animation itself is the problem — either it animates a non-compositor property, or its driver is a main-thread requestAnimationFrame loop. Paint flashing distinguishes the two: green rectangles every frame mean a repaint, so a non-compositable property is in play; no green but per-frame Main-track work means the driver is on the wrong thread.

The fix follows directly from the diagnosis: a repainting property becomes transform/opacity; a main-thread driver becomes a registered WAAPI or CSS animation; a layout animation becomes FLIP; and unavoidable per-frame computation moves to a worker. The one anti-pattern to retire is reaching for will-change as a first response to jank — it promotes a layer, which can help a genuine compositor animation but does nothing for a forced reflow or an expensive paint, and left permanently it just costs memory. Diagnose first, then apply the specific fix, and verify in the same trace that the Main track went quiet.

Honouring Reduced Motion

Performance and accessibility meet at prefers-reduced-motion. A compositor animation is cheap, but for users who experience motion sickness it can still be harmful, so non-essential motion belongs inside @media (prefers-reduced-motion: reduce) where it is shortened, replaced with a simple fade, or removed. This is free on the performance axis because it removes frames rather than adding them — an animation you do not run is the cheapest one there is — and for the meaningful fraction of users who set the preference, honouring it makes the experience strictly faster as well as more comfortable. Author the full animation as the enhancement and the reduced-motion branch as the safe default, and both goals are served at once.

The same reduced-motion query is a useful escape hatch for expensive-but-decorative effects that resist the compositor fast path. If a particular flourish genuinely needs a property that forces paint, gating it behind the default-on animation branch means it never runs for reduced-motion users and can be kept modest for everyone else. Treating motion as opt-in enhancement rather than baseline keeps both the frame budget and the accessibility contract intact, which is the posture this whole section argues for: spend animation budget deliberately, and never spend it where the user has asked you not to. In a component library, reading the preference once and exposing it as a token that every animated component consumes makes the contract consistent across the app rather than something each author has to remember to honour.

The One Rule Behind Every Pattern

Every technique in this section is an application of a single rule: keep the thing that advances an animation off the main thread, and keep the properties it changes to transform and opacity. Register animations with CSS or the Web Animations API rather than driving them from requestAnimationFrame; convert layout animations to FLIP so only a transform changes per frame; push unavoidable per-frame computation to a worker; and honour reduced-motion so the cheapest animation — the one that does not run — is available to those who want it. When an animation janks, the diagnosis always comes back to a violation of that rule, and the fix always restores it.

Frequently Asked Questions

Related Guides

• Compositing and GPU Acceleration — the parent topic covering layers, promotion, and the compositor thread.
• Transform and Opacity Best Practices — why these two properties skip layout and paint.
• Animating transforms without layout thrash — the FLIP technique and will-change promotion in practice.
• React concurrent rendering vs forced reflow — how framework re-renders interact with per-frame layout.
• Tracking long animation frames — attributing janky frames to a script or layout source.