3D websites and WebGL experiences that survive a mid-range phone

What this actually solves

Two things bring a brand to this page and only one of them is really about 3D.

The first is sameness. Open five premium sites in five tabs and you will struggle to tell them apart — a full-bleed hero photograph, a three-column grid, a serif headline over a muted video loop. The category has converged. Money spent on another photoshoot no longer buys separation, because the competitor spent it too. A page where the product turns, opens and is travelled through under the visitor's own scroll does buy separation, for the simple reason that almost nobody on the same shortlist has one.

The second is attention. Someone operating a page behaves differently from someone reading one. They stay, they move the thing, they look at it from underneath. On a commerce page, time spent on the product is the step that comes immediately before a purchase decision, and this is the honest answer to give a finance director who asks what 3D returns — not "it looks incredible".

There is a third thing nobody says out loud, and it explains why an agency will quietly steer you away from this work. The fear is not being able to make it fast enough on a phone, and it is a reasonable fear. One rule governs this entire field: a 3D page has to be interactive on a mid-range Android over a mobile connection within a few seconds, or it has failed, however good it looks on the studio's laptop. Your customer is not on a workstation with a discrete GPU. They are on a mid-priced phone, on 4G, possibly in a moving vehicle, with no patience at all. Everything below is organised around that one constraint rather than around the visuals.

How the work runs

1. Three questions, then a storyboard. Before anything else we ask whether a 3D file already exists and in what format, how many distinct moments the story needs, and what share of your traffic is mobile — that last figure is already sitting in your analytics and it sets the entire technical budget. Then the scroll is storyboarded: each beat, where the camera sits and what it looks at as actual coordinates, what the model does, and where the copy lands. You approve that document before a line of code is written. Three to five days.
2. A written performance budget. A one-page document naming the target device class, the total 3D payload ceiling, the time to first rendered frame on a mobile connection, the sustained frame rate while the camera is moving, and hard limits on triangles on screen, draw calls and texture size. It goes to you signed. Its real value arrives later in the build, when a late addition has to be weighed against a number instead of argued about. One day.
3. Asset preparation. This is usually the longest phase and it is not glamorous. A factory CAD file contains every screw, washer and internal bracket, because it was made for manufacturing, not for a browser; the parts the camera never sees are deleted first. Then geometry is joined by material to cut draw calls, decimated while watching where the silhouette starts to break, UV unwrapped, given readable material names, and exported as GLB. Finally it goes through the gltf-transform CLI for Draco geometry compression and WebP or KTX2 textures, which takes weight out of what has to be downloaded rather than out of the model, leaving the same triangle count and the same silhouette. One to three weeks.
4. Build the scene. React Three Fiber and drei, with gltfjsx turning the GLB into a component. Scroll progress is held in a ref rather than component state, so the page is not re-rendering on every frame; camera moves are damped so motion settles rather than snapping when scrolling stops. Real-time shadow maps are replaced with contact shadows, and a full environment preset with a small custom HDRI. Reduced-motion preferences are respected from the start, not retrofitted. One to three weeks.
5. Test on real hardware, over USB. A phone connected to the machine, remote debugging through Chrome, real frame rate and real memory rather than a simulation. Where the budget is missed, cutting happens in a fixed order — cap the device pixel ratio, shrink the environment map, drop contact-shadow resolution, delete meshes the camera never approaches. Three to five days.
6. Integrate, then hand over. Into your CMS, with a poster image and lazy loading so the 3D file is not downloaded until someone actually scrolls to it, assets served from a CDN with correct caching headers, and the agreed fallback wired in. Handover includes what the model is, how it was compressed and what has to be re-run if you replace it. Three to five days.

What moves the price

The range is $2,000–$20,000 over 3–10 weeks, and three things set where you land in it.

Whether the model exists. Being handed a usable product file and being asked to build one from photographs and drawings are two different projects rather than two versions of one — the first starts at optimisation, the second starts at modelling from nothing. This is quoted as its own line, never folded invisibly into the build, so you can see what you are actually paying for.

How many beats the story has. Each moment in the scroll is its own camera path, its own copy, its own state and its own testing on a phone. Three beats and eight beats are not the same project even though they use the same model.

Where it has to live. A standalone page is straightforward. The same experience embedded inside an existing WordPress, Shopify or Webflow theme has to survive that theme's asset pipeline, script loading and cache, and that integration is frequently a larger share of the hours than the 3D itself.

What usually goes wrong

The demo gets approved on a laptop. Everyone is delighted in the meeting room. Three weeks later someone opens the link on their own phone in a taxi and it stutters, and now there is a fortnight of unbillable rescue work and a damaged relationship. The fix costs nothing and almost nobody does it — every demo goes out as a link to be opened on a phone first, and the laptop version is the bonus.

A reference link sets the expectation while the budget sets something else. The brief arrives with a link to one of the famous immersive sites and the words "like this". Those came out of large teams and long schedules, and the budget behind them is not the budget in front of you. That gap has to be named in the first conversation, with a truthful example of what this budget does produce, because discovering it in week six is what turns a good project into a dispute.

Nobody writes down what happens on a weak device. Without an agreed fallback, the simplified mobile version reads as a failure instead of a plan, and gets argued about at the worst possible moment. One line in the quote — that devices below the performance target receive a specified simplified version — converts that argument into a decision you already made.