Video, WebGL or CSS: what to use for a hero background

The comparison at a glance

Choose by what the hero has to do: video shows, WebGL responds, and CSS carries the text and interface. Support is close to even between video and WebGL, according to Can I use (opens in a new tab), so the choice comes down to weight, looks and what breaks first.

Use video when the image is the idea

If the first thing a visitor should feel comes from the picture itself, use video. Light on real materials, weather, skin and landscape are the hardest things to reach in real time, and a good loop has them from the first frame. Quick procedural scenes tend to look cheap beside photography, and we have thrown out several for that reason.

Weight is the first risk. Our median phone loop, 1.35 MB, adds more than half of a whole median mobile home page, which weighed 2,362 KB in July 2025 according to the Web Almanac (opens in a new tab). The second risk is playing too much at once. On a 2× screen, the autoplaying previews on our own catalogue dropped scrolling from 60 to about 30 frames per second, and it went back to 60 with them off. Read our guide to making a seamless video background before encoding.

Use WebGL when input changes what you see

WebGL earns its cost when the pointer, the scroll or live data changes the picture. A particle field that bends around the cursor, or glass that responds to the visitor, cannot be recorded in advance. If nothing responds, a recorded video will usually look better for less work. 53 of our 64 websites use WebGL somewhere, and these rules keep the cost down:

• Render on demand. With nothing moving, the page does no work. We measured 0 draw calls at rest and 16.7 ms per frame while animating, on a physical GPU.
• Cap the pixel ratio at 2. Sustained frames over 25 ms can lower it further, down to 0.75, without changing the design.
• Pause the canvas off screen. Nobody needs it running behind the footer.
• Detect software rendering first. SwiftShader and llvmpipe take seconds to create a context and run at 10 to 15 frames per second. Read WEBGL_debug_renderer_info (opens in a new tab) and go straight to the static image.
• Test on a physical GPU. Headless browsers usually render in software, which says little about how the page will perform for visitors.

A <canvas> is not on web.dev’s list of elements for Largest Contentful Paint (opens in a new tab), so the metric usually reads your headline or static image. It will not warn you about a slow engine, so measure that separately.

To compare the techniques in motion, browse our hero section examples.

Use CSS for type, interface and simple gradients

CSS has almost no download cost and no engine that can fail, so let it do everything it can. Text reveals, panels, hovers, gradients and drawn lines rarely need more. web.dev recommends (opens in a new tab) animating transform and opacity, which browsers can handle without recalculating layout or repainting.

Its limit is GPU memory. On one template, black tiles flickered across the page, with edges at multiples of the tile size. It looked like a layout bug, and the cause was three layers: a grain layer at 200% of the screen, a full-screen mask with a blend mode, and hidden layers still in the tree. Removing them fixed it. We collect more cases like this in nine bugs that break animated websites.

Combine them when one job needs two tools

The best answer is often a mix, with video for the image, WebGL for the moment of interaction and CSS for the interface. 21 of our 64 websites use both video and WebGL. On APSIS, we rejected 4 approaches to changing between editions: a shader portal over a photo, generated video transitions, a live photo with particles and a full particle world. The version we accepted kept the generated frames as 5-second loops and did only the change itself in WebGL, in 0.62 seconds.

Keep the text in HTML whatever you choose, so it can be read, translated and indexed. If you are writing this into a prompt, state which tool owns which job, as we explain in how to write a website prompt.