Does 3D slow your website down?

The short answer, with the figures

The homepage you are one click away from runs a complete three-dimensional scene. An Earth with modelled coastlines, an orbit, an astronaut, type built as geometry rather than drawn as an image, and lighting with real shadows.

Here is what a first visit downloads:

• HTML: 33 KB, which travels as 6.9 KB compressed.
• JavaScript: 630 KB across six files, which travels as 186 KB compressed.
• Typefaces: 252 KB, served from our own domain rather than fetched from Google.

That 186 KB figure includes everything. The three.js library, the scene, every model, and every line of code the site itself runs.

For comparison, three.js version 0.185 on its own is 365 KB minified, or 87 KB once compressed for transfer. So roughly half of what our homepage ships is the library, and the other half is an entire website. You can verify all of this in about thirty seconds: open the developer tools in your browser, go to the network tab, and reload.

We are not claiming this is a record. Plenty of studios do better. The point is narrower and more useful to you: a full 3D scene does not require a heavy site, and any studio telling you the weight is unavoidable is telling you about their process, not about the technology.

Where the weight comes from in a 3D site

Four things make a 3D site heavy, and only one of them is the library.

The models are usually the worst offender by a wide margin. A model exported straight out of Blender or CAD with no preparation can run to several megabytes on its own, because it carries geometry no one will ever see at the size it gets displayed. A car configurator built from the manufacturer’s engineering file is the classic case: hundreds of thousands of polygons describing bolt threads, rendered at 400 pixels across.

The textures come second. A single 4K texture map is heavier than the whole of three.js. Sites ship four or five of them without anyone noticing, because in a modelling tool they cost nothing.

The shaders cost time rather than bytes. They compile on the visitor’s device on first run, and that compilation blocks everything else while it happens. It is the reason a site can show good download figures and still feel stuck.

And the library itself, which is the part everyone worries about and the smallest of the four.

Which Core Web Vitals a 3D scene puts at risk

Google does not have a penalty for 3D. It has no way of knowing whether a canvas contains a rotating planet or a static logo. What it measures is what the visitor experiences, through three numbers:

• LCP, how long until the largest thing on screen has drawn. Under 2.5 seconds.
• INP, how long the page takes to respond after you interact with it. Under 200 milliseconds. It replaced FID in 2024, and it is stricter, because it measures every interaction rather than only the first.
• CLS, how much the layout jumps around while loading. Under 0.1.

Read those three and it becomes clear where a 3D site actually gets into trouble, and it is rarely download size. It is INP. A scene that compiles shaders on the main thread while someone is trying to scroll produces exactly the symptom INP was designed to catch.

It also explains a trap worth knowing about. If the 3D canvas is the largest element on screen, it becomes the LCP element, and your LCP is now hostage to the slowest part of your page. Draw something else first and the number belongs to you again.

The decisions that keep it fast

None of this is exotic. It is a handful of choices made early, and they cost nothing if made early and a rebuild if made late.

• Build the geometry for the size it will be seen at, not the size it was modelled at. Most of the weight in a typical model is detail that is smaller than a pixel on delivery.
• Compress the textures and size them to what is actually visible. A texture that never fills more than a quarter of the screen does not need to be 4K.
• Let the page draw before the scene loads. The visitor sees the site, then the scene arrives. Nobody perceives this as waiting.
• Do not render when nobody is looking. A scene that has scrolled out of view, or a tab in the background, should stop. This is the single change that most often fixes a laptop’s fan spinning up.
• Decide what happens on a mid-range phone, deliberately. Sometimes the answer is a reduced scene. Sometimes it is a still image. What it should never be is the desktop scene, unchanged, and hope.

When 3D genuinely does cost you speed

We build these, so it is worth saying plainly where the trade-off is real rather than pretending it never is.

A 3D scene will always cost more than no scene. Even done well, that is around 87 KB of library plus whatever the scene itself weighs, and a first frame that arrives later than a page of text and images would. On a good connection nobody notices. On a poor one they do.

Older phones are the harder constraint. WebGL runs on the graphics processor, and a phone from five years ago on a warm day will throttle. You can design for that, and we do, but a site that is fast on a recent iPhone is not automatically fast on a four-year-old Android.

And there is a cost that never shows in any measurement: the scene has to be maintained. Browsers change, graphics drivers change, and a scene that works today needs checking. A page of text does not.

If your audience is mostly on old devices and poor connections, that changes the answer, and it should.

How to check anyone’s claim in five minutes

Including ours. If a studio tells you their 3D work is fast, this is how you find out without taking their word for it:

• Open one of their live projects on your phone, on mobile data, not on the office wifi.
• Run it through PageSpeed Insights and read the field data section if there is one. That is real visitors, not a simulation.
• Scroll immediately, while it is still loading. If scrolling stutters, the main thread is busy, and that is the INP problem.
• Leave the tab open for a few minutes and notice whether the machine gets hot. If it does, the scene is rendering with nobody watching.
• Ask for the addresses of the projects, not screenshots. A recording of a scene tells you nothing about how it performs.

Any studio that builds this properly will be comfortable with all five. We would rather you ran them on us than took the paragraph at the top on trust.