At sixty frames per second, you have about 16.7 milliseconds to build a frame — and your browser needs some of that too. Everything that makes a 3D experience feel alive has to fit inside that sliver of time, sixty times a second, on a phone someone bought four years ago.

It's easy to make a WebGL scene that's stunning on a workstation. It's hard to make one that's stunning on a mid-range Android with battery saver on. The gap between them is a performance budget — limits you decide before you fall in love with an effect.

Know where the milliseconds go

• Draw calls. Every separate object has overhead. Merge geometry and instance ruthlessly.
• Overdraw. Transparent, additive particles make the GPU shade the same pixel many times. Fullscreen blended clouds are where frame rates die.
• Shader complexity. A fragment shader runs once per pixel — millions of times per frame. Move math to the vertex shader when you can.
• Main-thread JavaScript. Rebuilding arrays and allocating every frame competes with rendering.

You don't optimize a scene by making everything faster. You optimize it by deciding what you're willing to not do.

Particle systems: spend your points wisely

• One geometry, many points. One draw call for tens of thousands of particles.
• Morph on the GPU. Interpolate two buffers in the vertex shader; only swap targets when the scene changes.
• Scale to the device. Halve the count on mobile and cap the pixel ratio.

Reduced motion is a feature, not a fallback

Some visitors get motion sick; some are on a device that can't keep up; some told their OS they want less movement. Honoring prefers-reduced-motion is part of the design — the still version is its own beautiful poster. The same instinct keeps a real, semantic DOM under the canvas, which protects your SEO and first paint.