Short answer: brief the content and structure of the page as if it had no three-dimensional scene at all, then add the 3D work as a layered enhancement with an explicit budget for its assets, a lazy-loading plan, a reduced-motion path, keyboard access, and a fallback image for when it cannot run. A 3D scene that only works well on one fast device in good conditions is not finished; it is finished once it degrades gracefully everywhere else too.
What should exist before any 3D is added?
Every page needs a version that works without WebGL: the words, the navigation, and the calls to action should be complete and legible on a page that never loads a single 3D asset. This matters for people on older devices, people with motion or bandwidth constraints, and for search engines and AI assistants, which read the semantic content of a page rather than what renders inside a canvas. If the message only exists inside the 3D scene, it effectively does not exist for a large share of your actual audience.
Writing the plain-page version first also clarifies what the 3D scene is actually for. It should support the message, not carry it: the same headline and explanation should make sense whether or not a visitor ever sees the animation.
How do you brief the technical constraints?
- Set a maximum size, in kilobytes after compression, for the 3D assets and code on any single page, and hold to it deliberately rather than discovering it after the fact.
- Require the 3D scene and its assets to load lazily, only once the section is near the viewport, rather than blocking the rest of the page.
- Require a static poster image or a lightweight fallback for browsers or devices that cannot or should not run the scene.
- Require the scene to respect the operating system's reduced-motion setting, replacing continuous animation with a still or minimally moving state.
- Require every interactive part of the scene to be reachable and operable by keyboard alone, with a visible focus state and a text description of what it does.
- Require the scene to pause when it is not visible on screen, so it does not use battery or processing power for something nobody is looking at.
- Ask for the actual measured load time and interaction responsiveness on a mid-range phone, not only on the development machine.
What does "fast" actually mean here?
"Fast" is not a feeling, it is a small number of measurements: how long before the main content is visible, how long before the page responds to input, and how much data had to move before either of those happened. A brief that only says "make it feel premium" or "make it fast" leaves those numbers undefined, and undefined numbers tend to grow over the course of a project. Put a rough figure on each one early, even a provisional one, so there is something concrete to check the finished work against, and expect the acceptable figure to vary with the device and connection you are testing on.
| Constraint | What to ask for in the brief |
|---|---|
| Content without WebGL | A complete, legible page with no 3D assets loaded |
| Loading behaviour | 3D assets load lazily, not on initial page load |
| Motion sensitivity | A reduced-motion alternative that removes continuous animation |
| Keyboard access | Every interaction reachable and operable without a mouse |
| Fallback | A static image or simplified view when the scene cannot run |
| Real-device measurement | Load time and responsiveness checked on an actual phone |
When this is the wrong choice
An interactive 3D scene is the wrong choice for a page whose message is a simple, factual lookup, such as a pricing table or a contact form, where the scene would add load time and complexity without adding understanding. It is also the wrong choice when the team building or maintaining the site has no way to test on a range of real devices, since a scene that was never checked outside one strong development machine is a common way for a "fast" site to become a slow one after launch. Motion and depth are worth their cost when they explain a relationship or make an interaction more legible, not as decoration on their own.
How we approach it at Ribhu Labs
We write the page's content and structure to stand on its own first, then layer motion and three-dimensional detail on top with an explicit budget, lazy loading, a reduced-motion path and full keyboard access, and we check the result on real phones rather than only in a browser on a development machine. Read more on the Websites & experiences page, and see the same constraints applied to a live scene in the mechanism study in the Lab, which is an illustrative browser demonstration built under exactly these limits.