Canvas or CSS: choosing the right engine for background effects

The question behind the question

"Which is faster?" is the wrong question — a blurred CSS orb and a 300-particle canvas are both 60fps on a laptop and both janky on a 2019 mid-range phone. The right question is: what does your effect NEED to do? Interaction and physics push you to canvas; ambient drift pushes you to CSS.

Choose CSS when…

• The motion is ambient — drifting orbs, marquee strips, morphing blobs. The compositor runs these on the GPU even when the main thread is busy.
• You want zero JavaScript — pure CSS animations survive hydration failures, ad-blockers and framework re-renders.
• The effect must scale to any viewport — vmin units and percentages beat canvas resize math.

Choose Canvas when…

• Elements interact — mouse gravity, collisions, links drawn between neighbors. Compositor-only CSS can't compute relationships.
• You need physics — gravity, drag, springs. Canvas gives you a frame loop; CSS gives you easing curves, period.
• Particle counts go past ~50 — DOM nodes per particle will murder layout; a single canvas redraws thousands cheaply.

The cost profile nobody mentions

CSS blur is the sleeper cost: filter: blur(80px) forces massive compositor layers, and stacking four of them can out-cost a modest canvas. Meanwhile a canvas at 300 particles costs nothing until someone scrolls — then it keeps burning battery at 60fps whether anything changed or not. CSS animations also run forever, but the compositor can skip frames when the tab is hidden; a rAF loop you don't pause keeps burning.

Practical rules: pause canvas loops on visibilitychange, cap particle counts on mobile (window.innerWidth < 768 → half), and prefer one blurred orb over three.

The hybrid answer

The most premium pages use both: a pure-CSS aurora base (free, always-on) plus ONE canvas signature moment that starts on first interaction. The base never costs a main-thread frame; the canvas only runs when it's the show.