Web 3D is a real-time renderer with a hard extra constraint: everything must download before it can be seen, over a connection you do not control.
Size is the first budget
A game installs once. A web page downloads every visit. A model that would be unremarkable in a game build is unacceptable on a landing page, because the user is waiting and their patience is measured in seconds.
The levers
- GLB, always. One file, binary, embedded textures.
- Draco compression on geometry — substantial reduction, with a decode cost on load.
- KTX2 / Basis textures, which transcode to whatever GPU format the device supports and stay compressed in memory. The single biggest win for most web scenes.
- Aggressive polygon reduction. Web viewers are usually looking at one object; it does not need game-scene density.
- Fewer, smaller textures. 1K is often enough for an object filling a third of a screen.
Progressive loading
Show something immediately. A low-detail version that loads instantly and refines, or a poster image while the model streams, beats a blank canvas — the perceived load time matters more than the actual one.
The renderer
Browser 3D runs through WebGL or WebGPU. WebGPU is faster and support is still uneven, so most production work targets WebGL with WebGPU as an enhancement. Established libraries handle the difference.
Mobile browsers
Where most of the traffic is, and the tightest constraint: weaker GPUs, less memory, metered connections, and a browser that will discard your context if the user switches tabs. Test there first, not last.
Generated assets for web
A raw reconstruction is far too heavy — dense geometry and a large texture. The reduction path is the same as for games but more aggressive, and the payoff is more visible, because the user is watching a progress bar rather than a loading screen they expected.