Every 3D element on a page is a trade. You are spending download size, main-thread time, and GPU memory to buy attention and a sense of craft. That can be an excellent trade. It stops being one the moment the spend is invisible to you.
The three budgets
Treat a 3D scene as drawing from three separate budgets, because a page can pass one and fail badly on another.
- Transfer: the renderer, geometry, and textures your visitor has to download before anything moves.
- Main thread: the JavaScript that parses and sets up the scene, which blocks interaction while it runs.
- Frame time: the per-frame cost of drawing, which is what makes scrolling feel smooth or sticky.
A common mistake is optimising only the first. A scene that downloads quickly but recomputes lighting on every frame will still feel worse than a heavier one that idles when off screen.
What actually helps
Build geometry in code where you can, rather than shipping model files. A shape defined by a few dozen lines costs kilobytes rather than megabytes, and it stays sharp at any size.
Stop rendering what nobody is looking at. A scene that keeps its render loop running while the visitor reads the footer is burning battery for no one. Tie the loop to an intersection observer and let it go quiet.
Generate reflections locally instead of fetching an environment map. A handful of area lights arranged around the subject will give you believable metal without a multi-megabyte HDRI download, and it works offline.
Cap the pixel ratio. Rendering at the full device ratio on a high-density phone screen can mean four times the pixels for a difference almost nobody can see.
When to say no
If the 3D does not carry meaning — if it is decoration that could be a still image without losing anything — then it should probably be a still image. The technique earns its cost when it shows something a flat picture cannot: a product from every angle, a process unfolding, a form the visitor can turn over themselves.