interanimate

Search documentation

Search pages and sections of the interanimate spec

Performance

The response, frame, and robustness budgets interanimate holds itself to, and how it degrades when it can't meet them.

In interface motion, performance isn't a separate concern from feel — it is feel. A dropped frame during a drag reads as the interface stumbling. A 300 ms main-thread stall before a press state reads as the interface ignoring you. This page defines the budgets interanimate holds itself to.

Three budgets#

1. Response budget — 100 ms#

From input start to first visible acknowledgment. This is the threshold at which people feel they're directly causing what happens on screen. It's the most important budget in the framework (Principle 1).

For context, Google's Interaction to Next Paint metric treats 200 ms or less from input to the next paint as "good," and over 500 ms as "poor." interanimate targets the stricter perceptual threshold for its own acknowledgment frames, so that the framework never consumes an application's INP budget.

2. Frame budget — every frame, on time#

While a value is moving, each frame should be delivered on time at the display's refresh rate. Smoothness is about consistency more than raw frame rate: a steady motion beats a fast one that hitches.

3. Robustness budget — under stress#

Motion must hold up — or gracefully back off — on low-end devices, under heavy main-thread load, in low-power modes, and under rapid or erratic input. Rauno Freiberg's test applies to every intent: can you break it by scrolling fast, or when the battery is low?

Principles of cheap motion#

These are informative guidelines for implementations and authors; the normative rules follow.

  • Prefer channels the browser can composite. Transform and opacity can typically be animated without recalculating layout or repainting; properties that change layout (width, height, top, left, margins) generally cannot. Kowalski's guidance is to animate only transform and opacity wherever possible. interanimate's spatial channels are defined so they can be expressed as transforms.
  • Clip and mask rather than resize when revealing content, so the layout stays fixed while the visible area changes.
  • Do the minimum synchronously. On input, produce the acknowledgment frame first; defer everything else.
  • Retarget, don't queue. Rapid repeated triggers (mashing a toggle, scrolling fast through items that animate) change the target of the motion in flight. They never stack up a backlog of animations that keep playing after the person has stopped.
  • Release resources at settle. Once a value is settled, nothing should keep running on its behalf.

Rules (normative)#

  1. The framework never delays the acknowledgment frame for any non-essential work.
  2. Intents prefer compositor-friendly channels. An intent that requires a layout-affecting channel declares it.
  3. Repeated triggers retarget motions in flight; they never queue.
  4. No work runs for a value that is settled and unowned.
  5. Degrade toward less motion. When the framework cannot sustain the frame budget, it shortens or removes non-essential motion (decoration, stagger, ambient effects first; then spatial channels of orientation intents, substituting effects) rather than stuttering through it. Direct manipulation is the last thing to degrade — it is the person's own movement.
  6. Degradation never changes outcomes. A dismissed sheet is dismissed whether or not it was thrown.

Degradation ladder (informative)#

When headroom drops, interanimate removes motion in this order:

  1. Ambient and looping decoration
  2. Stagger (items enter together)
  3. Bounce (character falls to smooth)
  4. Spatial channels of reveal, conceal, navigate, relocate, morph (substituted with effects, as under reduced motion)
  5. Effect channels (states change instantly)
  6. Never: direct manipulation tracking

This ladder intentionally mirrors the reduced-motion substitutions. An interface that degrades under load should feel like a calmer version of itself, not a broken one.

Measuring (informative)#

The framework's own test suite should measure, for every intent:

  • input-to-acknowledgment latency;
  • frame delivery consistency during motion;
  • behavior under artificially throttled CPU;
  • behavior under rapid repeated input (no queued backlog, no visual discontinuity);
  • interruption at arbitrary points in every motion (no jumps in value or velocity).