3D on the web is a garnish, not the meal
Three.js can make a site unforgettable or unusable, and the gap between the two is almost entirely about restraint. How I decide when 3D earns its megabytes.
The Awwwards front page is full of sites you would never build for a client. Beautiful, ten seconds to first paint, and unusable on the mid-range Android phone that most of the client's customers are actually holding.
That doesn't mean 3D is decoration. It means it needs a job.
Three questions before any WebGL goes in
- 01Does it communicate something a flat image cannot? Product configurators, spatial data and material previews all pass. A rotating abstract blob behind a headline does not.
- 02Does it survive being switched off? If the page is broken without the canvas, the 3D is load-bearing and it shouldn't be.
- 03What's the budget? A hero scene should cost under 300KB compressed and hold 60fps on a four-year-old phone. If it can't, it gets simpler.
The techniques that pay for themselves
- Instanced geometry over individual meshes — thousands of objects, one draw call.
- Shader-driven motion instead of per-frame JavaScript. The GPU is right there.
- Draco or Meshopt compression on every model, without exception.
- Render on demand rather than a permanent animation loop when the scene is static.
- prefers-reduced-motion respected properly: freeze the scene, don't just slow it down.
Progressive enhancement, seriously
The canvas mounts after the page is interactive, behind a dynamic import, only when the device reports enough capability and the user hasn't asked for reduced motion. Everyone gets the content. Some people get the atmosphere.
If removing the 3D makes the page worse but not broken, you've used it correctly.
Rajat Bharti
Senior Web Developer in Bengaluru, IN. Writes about performance, automation and the parts of client work nobody documents.
