An interactive 3D homepage in 94 kilobytes

Nearly every argument against putting real 3D on a small business website comes down to weight. The assumption is that a 3D scene means a heavy library, a slow first paint and a phone that gets warm. It is a reasonable assumption and we wanted to know whether it is true.

So we built one, on this site's homepage, and then measured all of it.

What we measured

Every file the homepage requests, at the size it actually crosses the network. Text files are counted after gzip because that is what a correctly configured server sends. Font files are counted uncompressed, because WOFF2 already contains compression and re-compressing it saves nothing.

Measured 31 August 2026. 96,763 bytes is 94.4 KB across 7 requests, none of them to a third party.

Against the rest of the web

The HTTP Archive Web Almanac publishes the distribution of page weight across millions of real sites. Their 2025 figures put the median mobile page at 2,164 KB and the median desktop page at 2,412 KB. Home pages specifically run heavier, at a median of 2,710 KB. Even the tenth percentile, meaning the lightest ten percent of the web, sits at 516 KB on mobile.

This page is 94.4 KB. That places it well below the lightest decile of the web while carrying an interactive 3D scene, two self-hosted variable fonts and a full stylesheet.

Median figures from the HTTP Archive Web Almanac, 2025 page weight chapter and 2024 request counts.

Where the weight actually went

The interesting result is which part is expensive. The 3D scene is 4.7 KB over the wire. The two fonts are 80.6 KB, which is 83 percent of the page.

The 3D scene costs 4.7 KB. The typography costs seventeen times that. Almost nobody argues about the typography.

That inversion is the finding worth taking away. The thing everyone treats as the expensive luxury is a rounding error next to a decision nobody questions.

What made the scene cheap

We wrote the renderer rather than importing a 3D engine. To put a number on what that saved, we measured the actual library.

Three.js version 0.128.0 as published to npm, file three.min.js. Gzip level 9.

Over the wire that is a factor of 31. The raw file comparison suggests a factor of 44, which overstates it, because minified JavaScript compresses extremely well and the raw number is not what anyone downloads. We report the gzipped figure because it is the honest one.

The saving is only available because the scene needs a narrow set of operations: projecting points, sorting by depth, drawing circles and text, and hit testing clicks. No lighting, no materials, no shadows, no model loading. A scene that needed those would be a slow reimplementation of a better library and we would import it without hesitating.

What this does not prove

That a page is light says nothing about whether it feels fast, which depends on server response time, render blocking, layout stability and the device in someone's hand. Weight is one input to that and not the whole picture.

It is also a single page on a single site, measured once. It is a demonstration that the ceiling is much lower than assumed, not a claim about what any given site should weigh.

We have not yet measured this against a mid-range Android device on a real mobile connection, which is the test that would actually matter to a customer. That is the next piece.

Repeat it yourself

• Open your own site with developer tools on the network tab and hard reload it.
• Read the transferred column, not the size column. Transferred is what your visitor pays for.
• Sort by size and look at the top three. On most small business sites they will be an image nobody resized, a font family loaded in six weights, and an analytics or chat script.
• Count how many requests go to domains you do not own. That number is usually the surprise.

The method here is deliberately simple so anyone can check our numbers. If you repeat it on this site and get something different, tell us and we will publish the correction.