GPU acceleration in CSS

renderingperformancecsshardhybrid~9 min

Slap yourself if

You think 'GPU-accelerated' means faster by default or still recommend translateZ(0) like it's 2014.

Why this exists

Because 'GPU acceleration' is one of the most abused performance myths in frontend — it hides real costs (layers, memory, overdraw) behind a feel-good label.

Mental model

The GPU doesn’t speed up your page. It changes which stage is expensive. You usually trade main-thread paint work for compositor work and GPU memory pressure.

  • Certain CSS properties can promote elements to compositing layers.
  • Promoted layers are painted into separate backing stores.
  • The compositor combines layers on the GPU each frame.
  • More layers reduce repainting but increase memory and compositing cost.
  • Forcing layers with will-change or 3D transforms without need.
  • Assuming transforms/opacity always avoid paint.
  • Creating many layers in scrolling lists and tanking GPU memory.
  • Chasing FPS while increasing input latency or battery drain.

CSS 'GPU acceleration' typically means compositing via separate layers; it can reduce repaint work but adds layer memory, overdraw, and compositing overhead.

  • Says GPU is always faster.
  • Treats translateZ(0) as a universal fix.
  • Ignores layer count and memory.
  • Cannot connect 'GPU acceleration' to compositing.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

What 'GPU acceleration' actually means in browsers

Why forcing layers can slow everything down

Composite-only animations: rare, conditional, and fragile

How to tell if the compositor is your problem

How GPU talk exposes cargo-cult optimization