- Case Study
- Performance
- Accessibility
- Web Design
Can a 3D Website Be Fast and Accessible? Our Redesign, Measured
How we rebuilt webpioneers.ca around one WebGL particle scene without hiding content from Google, screen readers or slow phones, with real Lighthouse numbers.
5 MIN READ
We're a new studio, so our own website is the most visible piece of work we have. In October 2026 we rebuilt it around a single animated 3D scene: a cloud of glowing particles behind the page that changes shape as you scroll, becoming a browser, a phone, a map of Metro Vancouver.
3D websites have a reputation for being slow, hard to use with a screen reader, and invisible to Google. The brief we set ourselves was to get the visual impact without those costs. Here are the five rules we followed, and the measurements that show where we succeeded and where we haven't yet.
Rule 1: The 3D Is Decoration, the Content Is HTML
Every word, link, price and form on the site is ordinary HTML, sent from the server ready to read. The 3D scene is drawn on a single canvas element (a drawing surface for graphics) that sits behind the page.
That canvas is marked as hidden from assistive technology, so a screen reader skips it entirely and reads the page as normal text. It also ignores clicks and taps, so it can never get between a visitor and a button. Search engines and AI crawlers see the same complete page whether the 3D runs or not.
If you take one thing from this post, take this one. When the important content lives inside a 3D scene, everything else gets harder.
Rule 2: Load the 3D Last
The 3D library is large, so it isn't part of the code that loads with the page. The browser shows the page first. Only once it's idle, or after three seconds at most, does it start fetching the 3D code. Until the scene is ready, a simple gradient background in the same colours stands in for it.
The headline doesn't wait for the 3D, and neither do the menu and buttons.
Rule 3: Fit the Scene to the Device
A gaming laptop and a three-year-old budget phone shouldn't get the same scene. Before starting, the site checks the device's processor cores, memory, whether it's a touch device, and whether it supports 3D graphics at all, then picks a quality level:
| Level | Particles | Who gets it |
|---|---|---|
| Off | 0 (gradient only) | No 3D support, or reduced motion turned on |
| Low | 6,000 | Phones with fewer than 8 cores or under 6 GB of memory, and anyone with data saver on |
| Medium | 18,000 | Phones with 8+ cores and 6 GB+, and computers below the High bar |
| High | 40,000 | Computers with 8+ cores and 8 GB+ of memory |
Pages that aren't the homepage use a lighter ceiling: service and city pages go no higher than Medium, and blog posts stay at Low, so reading is never competing with the background.
The choice isn't final. If the frame rate drops while you browse, the scene steps down a level on its own. When you switch to another tab, it stops drawing entirely, so it isn't draining your battery in the background.
Rule 4: Respect Reduced Motion
Phones and computers have a setting, often called Reduce motion, for people who get dizzy or distracted by animation. When it's on, our site switches to a calmer version: no 3D scene (just the static gradient), no smooth-scroll effect, no custom cursor or tilting cards, and text appears straight away instead of animating in.
Nothing is lost. Every page has the same content and works the same way.
Rule 5: One Scene, Not Ten
It's tempting to give every section its own 3D widget. Each one costs memory and loading time, and browsers limit how many can run at once. We use one scene for the whole site. It stays in place as you move between pages and simply changes shape.
Smaller effects, like the ripple when you hover over a portfolio card, use lightweight built-in browser filters instead of more 3D. We also skipped the usual loading screen: it would have made every visitor wait before seeing anything.
The Numbers
We set targets before starting. On October 12, 2026 we measured the live site with Lighthouse's mobile test, which simulates a mid-range phone on a slow connection. We ran it three times per page and show the middle result:
| Measure | Target | Homepage | Service page | Blog post |
|---|---|---|---|---|
| Accessibility score | 95+ | 100 | 100 | 100 |
| SEO score | 100 | 100 | 100 | 100 |
| Layout shift (CLS) | under 0.05 | 0.000 | 0.000 | 0.000 |
| Performance score | 85+ | 72 | 70 | 75 |
| Main content visible (LCP) | under 2.5s | 5.0s | 5.0s | 4.8s |
Accessibility and SEO are where we wanted them on every page. The 3D scene hasn't cost anything there, which was the hardest part of the brief.
What's Still Over Budget
Speed is not where we want it. On a simulated mid-range phone, the main content takes around five seconds to appear, double our target. One of our homepage test runs, on a first visit with nothing cached, also showed a layout shift well above target.
The pages aren't slow to download. The server responds in about a quarter of a second and nothing blocks the browser from starting. Something in the newer pages is holding back the first paint, and finding it is our next job. For the plain-English version of what these numbers mean, and what we already fixed, see our speed post →
Should Your Site Be 3D?
Probably not, at least not by default. For most service businesses, a fast, clear site that answers customers' questions will win more work than any animation. 3D earns its cost when the visual impression is the product: a brand launch, a product you want people to explore, or a portfolio, like ours, whose job is to show what's possible.
If you do go 3D, hold it to the same rules: content in HTML, 3D loaded last, scaled to the device, motion optional, and measured before and after every change.
Related service: UI/UX Design → · Custom Web Development →