How we keep a 3D site under two seconds on a cheap Android
Keeping a Three.js site fast on a mid-range phone: a weight budget, a device gate that runs before hydration, and a fallback that is a photo of the scene.
A live Three.js scene and a fast mobile page are not in conflict, although most 3D sites are built as though they were. Getting both is not a trick — it is a sequence of decisions taken in a particular order, and this is the order.
Decide the budget before the scene exists
The single most important line in a 3D project is a number in kilobytes, agreed before anyone opens Blender — and a note of which devices are allowed to download it at all. Everything downstream — how many polygons, what texture resolution, which effects — is then a negotiation against that number rather than a surprise at the end.
Without a budget, the scene is finished when it looks done, and it looks done at four megabytes.
Ship the page first, the scene later
The text, the layout and the buttons on our pages are plain HTML, built ahead of time. They paint immediately. The Three.js renderer is a separate chunk that is imported only after two things are true: the canvas is actually on screen, and the browser has told us it is idle. It is not on the path to first paint or to Largest Contentful Paint because it is not requested until both have happened.
This is the whole reason a 3D site can pass Core Web Vitals. The metrics measure the page; the scene is a layer that arrives after the page is already measured.
Decide who gets the scene before anything renders
A short inline script runs before any module code and answers one question: should this device draw a live scene? It checks the reduced-motion preference, the pointer type and viewport, the user agent, core count, memory and the data-saver flag. Then it asks the graphics driver what it is — and treats a software renderer, which is what a headless runner or a machine with hardware acceleration switched off reports, as the low-power device it effectively is.
Capable desktops get the scene. Everyone else gets a still frame. The decision is made synchronously, before hydration, which is what stops the page flashing from one to the other.
Make the fallback a photograph of the real scene
The still frame is not an illustration or an approximation. A headless script loads the actual scene, renders it, and captures it — one landscape, one portrait — so a phone sees exactly what a desktop animates. Encode it at a quality suited to whatever the scene actually is — a dark, out-of-focus backdrop tolerates far more compression than a product shot — and cap the candidate widths well below device pixel density, because it is a backdrop behind text rather than a photo anyone inspects.
The frames are regenerated whenever the scene changes, so they can never drift out of date.
Split what a phone can never use
Custom cursors, magnetic buttons and card tilt are mouse-move effects. A touch device cannot trigger them, so a touch device should not download them. They live in their own chunk, fetched only when a fine pointer is present. That one split, together with brotli compression, is usually the largest single reduction available in the JavaScript a phone downloads and executes — and blocking time falls with it.
Compress the assets like you mean it
Geometry goes through Draco or meshopt. Textures are resized to the largest size they will actually be displayed at and served as KTX2 or WebP. Nothing ships at the size it left the artist’s machine. This is unglamorous and it is where most of the megabytes are.
Measure on the device you are worried about
The gate should be a Lighthouse run against the production build, served brotli-compressed to mirror the CDN, with simulated throttling on a mid-range mobile profile. Not a developer laptop, not a browser with extensions installed, and not PageSpeed’s GPU-less runner for the desktop score — that runner draws the scene in software and swings thirty points between runs while the real metrics do not move. For desktop, field data from actual visitors with actual GPUs is the number that matters.
What it costs
Honesty about the trade: this is more engineering than a flat site, and the fallback means mobile visitors see a picture rather than a live scene. Whether that is worth it depends entirely on whether the scene does real work on your site — we wrote about when it does not. When it does, this is how you get it without paying for it in rankings, and the method is what we sell as 3D website development.
Sources and further reading
// TAGS
// RELATED POSTS
(02) // LET'S BUILD
START APROJECT