3D and scroll-driven websites that are still fast
Most 3D web work is beautiful in a case-study video and miserable on an actual phone. The interesting engineering problem is not making it look good — it is making it look good and load in under three seconds.
What we build
Scroll-scrubbed hero video, WebGL product scenes you can rotate, per-character headline reveals driven by a variable font's own axes, and section transitions tied to scroll position rather than to a timer.
The stack is Three.js and React Three Fiber for the 3D, GSAP with ScrollTrigger for choreography, and a smooth-scrolling layer bridged carefully to it. Everything is self-hosted; we do not put a third-party CDN on the critical path of a page whose whole job is to feel instant.
The performance work is the actual craft
On a recent fourteen-section 3D build we landed desktop 95 and mobile 82, with cumulative layout shift at 0.019 and total blocking time at 160 ms. Neither number came for free.
The layout shift took three wrong diagnoses. Lighthouse blamed a copy block; font swapping was not it; image sizing was not it. The answer only appeared when we sampled the heading's box on every animation frame and printed the frames where it changed — the text-splitting library was re-wrapping a two-line headline into three lines and back. Splitting by lines and words rather than by raw characters fixed most of it, and pinning the height rather than the min-height fixed the rest. 0.26 down to 0.019.
The blocking time had a similarly non-obvious cause. Loading the 3D through a dynamic import with server-side rendering disabled does not actually defer it, because the import fires on hydration and every section hydrates. It needed an intersection-observer gate as well. That, plus dropping a helper that quietly pulled a large environment map from a third-party CDN, took blocking time from 1,510 ms to 160.
Degrading honestly
A 3D scene should never be the reason a phone user sees nothing. We capture a poster frame from the live canvas itself, show it immediately, and fade the real scene in over the top once its first frame has drawn — so the section is never empty, and because the poster is a frame of the same object, the swap is invisible.
On this site the WebGL hero is gated off phones entirely. A continuous render loop on a throttled mobile CPU turns every frame into a long task; ours was generating long tasks indefinitely while the page sat idle. The scene now loads only where it can run well, and its library is dynamically imported so phones never download the 730 KB at all.
Reduced-motion is a real bailout, not a token one. If a visitor has asked their operating system to stop animation, the scene does not boot.
When 3D is the wrong choice
We would rather talk you out of it than build something that hurts your business, so here is when we say no.
If the primary job of the page is to rank for competitive search terms, spend the budget on content and speed first. 3D does not help you rank, and done carelessly it actively hurts Core Web Vitals, which do.
If most of your traffic is on older mid-range Android devices, the experience you are paying for is one a large share of your visitors will never see at full quality. We will gate it properly, but you would be buying something for the minority.
And if the product photography does not exist yet, that is the thing to fund. Every 3D scene we have built looked better after the source imagery improved, and no amount of shader work compensates for cutting assets out of screenshots.
Frequently asked
Will a 3D site hurt my search rankings?
It will if it is built badly, because Core Web Vitals are a ranking input and 3D is the easiest way to wreck them. Built properly, with the scene gated and deferred, it does not have to. That is the entire point of the approach described above.
Do you need 3D models, or can you work from photos?
We can build procedural scenes from reference photography, which is what we usually do for product work. Real models raise the ceiling considerably, so if you have them, send them.
What does it cost compared with a normal site?
More, and mostly in the performance and fallback work rather than the visuals. If the budget is tight, we would rather build you a fast conventional site than a slow spectacular one.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.