Shipping 3D on the Web Without Killing Frames Rate

Every client asks the same question eventually: can it be 3D, and can it still be fast? The honest answer is almost always yes — if you make the right calls early, not as a rescue mission after launch.

Budget your draw calls before you budget your design

The biggest mistake teams make is designing the scene first and optimizing later. By then, the geometry, material count, and lighting rig are already baked into the creative direction, and every optimization becomes a negotiation with the design team. We flip the order: agree on a frame budget (16.6ms for 60fps, no exceptions) before a single shader is written.

Suspense boundaries are not free organization, they're a rendering strategy

When you wrap multiple async resources in one Suspense boundary, the slowest one gates all the others. A single HDRI environment map that takes three seconds to fetch will hide your entire hero scene — geometry, particles, everything — even though none of it depended on that texture. Isolate anything that fetches over the network into its own boundary so your core visuals render immediately and reflections simply pop in when they're ready.

Instance everything that repeats

Particles, icons, repeated geometry — if you're drawing the same shape more than a dozen times, it belongs in an instanced mesh, not a loop of individual objects. This is the single highest-leverage change we make on every WebGL product configurator we ship.

Test on the device your users actually have

Your M-series laptop is not a representative testing environment. We profile every 3D build on a mid-range Android phone before it ships. If it holds 60fps there, it holds 60fps everywhere.