motion · perceived-performance
Compositor-only animation
also called GPU-accelerated animation (community), cheap properties (community), transform and opacity only (community), will-change (css), hardware acceleration (community)
An animation limited to properties the compositor can handle alone, usually transform and opacity, so it keeps running even when the main thread is busy.
A browser draws a page in stages: it works out where boxes go, paints them into layers, and
then composites those layers into the picture that reaches the screen. The first two stages
belong to the main thread, the one that also runs every line of script. The last one does
not. If an animation only changes things the compositor can decide by itself, the whole move
can be handed over once and then advanced without the main thread being consulted again. In
practice that means transform and opacity, which is why the shorthand for this idea is
often just “transform and opacity only”.
The payoff is what happens when the main thread is stuck. A long task, a burst of layout, a
few hundred rows being built: any of these blocks the thread for tens or hundreds of
milliseconds, and anything animated from script or from a layout-affecting property simply
stops being redrawn until the thread comes back. That stutter has a name of its own,
jank, and this is the escape it points to. The same slide written with left holds
still through the stall and then jumps; written with translate it keeps gliding, because
nothing in that stall was ever the compositor’s problem.
The property list is shorter than people hope. transform and opacity are the reliable
pair; filter and backdrop-filter are compositable in most engines, and a handful of
scroll-driven and view-transition animations get similar treatment. Everything that changes
geometry (left, top, width, height, margin, padding) forces layout on every
frame, and box-shadow, background-color and border-radius force paint. A useful
sanity check is whether the animated value could change the position of any other element:
if it could, the compositor cannot be trusted with it alone.
will-change is the way to ask for the layer before the animation starts, so the promotion
does not happen inside the first frame. It is a hint with a real cost, since every promoted
layer is memory the compositor holds, so it belongs on the few elements about to move and
comes off when they stop. The deeper caveat is that smoothness here is a local fix. A
compositor animation glides beautifully over a main thread that has stopped answering
clicks, and the reader still cannot use the page. It buys the motion, not the
responsiveness.
Which word?
| If you want | say |
|---|---|
| motion must stay smooth under load | compositor-only animation |
| naming why smooth-looking motion feels wrong | jank |
| an animation stutters and the cause is the code, not the curve | layout thrashing |
Related
See also: Frame rate