Real-time 3D in the browser has an image problem. Many people have met it as a spinning logo that froze their phone, a hero section that took ten seconds to appear, or a laptop fan that started the moment the page opened. The result is a common belief that 3D and a fast, search-friendly website exclude each other.
They do not. The problem is rarely the 3D itself — it is that the 3D is allowed to stand in front of the page instead of being layered on top of it. The rules below are the ones we apply to every scene we build. They come from a platform that runs a 3D homepage hero, a holographic 3D head and eight further interactive scenes, and still measures its pages against a performance budget on every build.
Rule 1: the page never waits for the 3D
Search engines and visitors judge a page by what appears first: the headline, the text, the main image, the button. In Core Web Vitals terms that is the Largest Contentful Paint. If a canvas has to download a library, compile shaders and build a scene before anything else shows up, every visitor pays for it.
So the page is built to stand on its own. Headline, text and calls to action render as normal HTML. The 3D canvas sits behind or next to them and joins later. If the scene never loads at all, nothing important is missing.
Rule 2: decide per device, not per website
A flagship phone and a five-year-old laptop should not get the same treatment. Before any 3D code is requested, a few cheap checks decide whether real-time rendering makes sense on this device:
- Does the visitor’s system ask for reduced motion? Then the scene starts still, or not at all.
- Is data-saver mode on? Then the library is not downloaded.
- Does the browser offer WebGL2? If not, a designed still image takes its place.
- Do the reported processor cores and memory point to a clearly weak device? Then the still version is the default.
- Where the browser reports no memory figure, a short frame-rate probe in the first seconds decides whether to keep the live scene or fall back.
Visitors who land on the still version are not locked out: a quiet “Load 3D anyway” button lets them opt in. The decision is a sensible default, not a wall.
Rule 3: load the library only where and when it is needed
three.js is excellent, and it is also a few hundred kilobytes of JavaScript. It should never be part of the bundle every page loads. We split it into its own chunk that is imported dynamically — and only when the element that needs it scrolls into view. On our own website, for example, the library is loaded on exactly three pages; every other page never downloads a byte of it.
Rule 4: render only what is visible
A render loop that keeps running while the scene is off screen, or while the tab sits in the background, burns battery for nothing. An intersection observer pauses the loop when the canvas leaves the viewport, the page-visibility API pauses it when the tab is hidden, and the pixel ratio is capped so that high-density screens do not quadruple the work.
Rule 5: fewer draw calls, not fewer ideas
Most slow scenes are slow because they ask the graphics card to draw hundreds of separate objects. Instanced rendering draws hundreds of identical shapes — tiles, points, markers — in a single call, each with its own position and colour. A 21 × 21 matrix of 441 animated tiles becomes one draw call. The idea stays rich; the cost stays small.
Rule 6: 3D must be accessible, too
A canvas is invisible to screen readers. Every scene therefore needs a text equivalent: a label that describes it, and — where the scene carries information — an alternative path to the same content. On our architecture model, for example, every discipline can be reached through a row of ordinary buttons as well as by clicking in 3D. Respecting the reduced-motion setting is part of the same principle.
Rule 7: the still version is designed, not an error message
The fallback is not a broken box with an apology. It is a designed image or a lightweight vector drawing that carries the same idea. For many visitors it is the version they will see, so it deserves the same care as the live scene.
A checklist for your next 3D project
- 1.Can the page be used fully before the 3D appears?
- 2.Is there a per-device decision before the 3D library is requested?
- 3.Is the library code-split and imported only when the scene comes into view?
- 4.Does the render loop pause off screen and in background tabs?
- 5.Are repeated objects drawn with instancing?
- 6.Is there a text equivalent and a non-3D path to the same information?
- 7.Is the still version designed as carefully as the live scene?
- 8.Are Core Web Vitals measured on every build, not once before launch?
If all eight answers are yes, 3D stops being a risk to your website and becomes what it should be: the part people remember.