What ambitious websites weigh

What we measured, and what it is not

We keep a library of websites captured as design references: the visually ambitious end of the field, heavy on 3D, WebGL and scroll-driven motion. Thirty-three of them carry a recorded transfer weight. This is what those weights look like when somebody adds them up.

Read the selection before the numbers. These sites were captured because they are unusual, not because they are typical, so nothing here describes the average website and no figure below should be quoted as if it did. It is a picture of the ambitious end of the web, measured rather than admired.

No site is named anywhere in this piece. The measurement is unflattering, the sites belong to other people, and every finding survives in aggregate. The script that produces the figures has no code path that can emit a hostname, so that is a property of how it is built rather than a promise we remembered to keep.

The numbers

Every site in the set is over 3 megabytes. Nine are over twenty. The lightest is 3.1 and the heaviest is 34.0, which is a range of roughly eleven to one inside a group of sites doing broadly the same kind of thing, and that spread is the most interesting number on the page.

The spread matters because it rules out the comfortable explanation. If ambitious visual work simply required thirty megabytes, the set would cluster near thirty. It does not. Sites in the same set, competing for the same attention, differ by an order of magnitude in what they ask a visitor to download.

What eleven megabytes costs a visitor

Weight is not a metric Google ranks on directly, which is why it gets treated as a secondary concern. It is better understood as the cause underneath the metrics that are ranked: the large image is a loading problem, the large script is a responsiveness problem, and the asset that arrives late is a layout stability problem.

It is also a cost that lands on the visitor rather than on the publisher. On a metered mobile connection the median site in this set consumes real money to open, and on a slow connection it consumes time before anything useful appears. Neither cost is visible from the machine the site was built on, which is the usual reason it goes unnoticed until somebody measures.

For comparison, and on the same basis of measurement rather than an estimate: our own pages transfer a median of 467 kilobytes on a cold mobile load, measured across eight routes. That is roughly one twenty-fifth of the median site in this set. We are not claiming the two are attempting the same thing, because they are not. The point is only that the numbers are separated by a factor, not by a margin.

Why this is a pipeline choice rather than a ceiling

The eleven-to-one spread inside the set is the evidence for this, and it is worth stating carefully because it is the actionable part. The lightest sites in the library are not less ambitious than the heaviest. They compress what they ship.

• Geometry can be compressed. A glTF asset that declares a mesh compression extension is materially smaller than one that does not, and the extension is declared in the file rather than inferred.
• Textures can be compressed. Shipping a stack of uncompressed images is the single most common way a 3D page becomes a thirty megabyte page.
• Still images can use a modern format, which is the cheapest saving available and the one most often skipped on sites that spent months on the motion design.

The tool that produced these weights records a related observation we are repeating rather than re-deriving: across the same library, only three sites compress anything at all. We have not re-run that particular measurement, so treat it as a note from the tool's own documentation rather than as a figure this piece establishes. It is listed in the limits for that reason.

There is a trap in checking this, and it is worth naming because it produced nine wrong claims in an earlier version of that work. The presence of a decompression loader in a page's JavaScript proves nothing about whether the assets are compressed. A page can ship the loader and ship uncompressed geometry. The only sound check reads the asset itself and looks for the declaration.

How stable these figures are

Published research about other people's websites has a short half-life, so here is the state of the set rather than an assurance about it. Of the 33 captures, 30 were recorded as unchanged at the last check and three as rebuilt since capture. Those three are measuring a page that has already been replaced.

One site in the set now disallows automated access where it previously allowed it. That is its owner's right, it is recorded rather than worked around, and it is the reason this kind of measurement has to be dated to be worth anything.

What to take from this if you are commissioning work

1. Ask what the page will weigh before it is built, and get a number rather than a reassurance. It is a design constraint, and constraints set early cost nothing.
2. Ask specifically whether geometry and textures are compressed, and ask how that will be verified. The answer that a loader is present is not an answer.
3. Test on a real phone on mobile data once, before launch. It takes ten minutes and it is the only step here that produces a visceral answer.
4. Treat a heavy page as a decision rather than an accident. Sometimes it is the right decision. It should still be one somebody made deliberately.

None of this is an argument against ambitious work. The set exists because we keep these sites as references, which is to say we admire them. It is an argument that the weight is separable from the ambition, and the eleven-to-one spread inside the library is the proof of it.

What this does not cover

• Selected, not sampled. This library was assembled as a design reference set, so it has no claim to represent the web, a sector or a country. The median here is not a typical page weight and must not be quoted as one.
• Thirty-three sites is a small number. Read the distribution as an illustration of a range rather than as a precise figure, and do not compute anything further from it.
• The claim that only three sites in the library compress anything comes from the measuring tool's own documentation. We did not re-run that measurement for this piece, and it is the one figure here that is not re-derivable from the recorded run cited above.
• Weight is measured for the captured pages, not averaged across whole sites. A site can be heavy where it was captured and lighter elsewhere.
• It measures what was shipped, not whether the shipping was worth it. Nothing here shows whether the weight buys something a visitor values, and on some of these sites it plainly does.
• Three captures are recorded as rebuilt since measurement, so their figures describe pages that no longer exist in that form.
• No site is named, which is deliberate and does cost the reader the ability to check any individual figure. The aggregate is checkable by re-running the script against the same state.

Sources

• Reference capture library, 33 visually ambitious websites. Transfer weight per captured site, read from the recorded capture state and aggregated. Only the weight, drift verdict and robots status fields are read; the hostnames are never touched, so the script cannot emit a site name. Published as aggregates only. Run: scripts/capture-weight.mjs, 2026-08-26, recorded in content/CAPTURE-WEIGHT.md.
• whatscene.in production build, 8 routes at 2 viewports. Cold-cache transfer weight measured in headless Chromium with a fresh browser context per route, used here only for the order-of-magnitude comparison. Run: scripts/vitals-evidence.mjs, 2026-08-25, recorded in content/VITALS-EVIDENCE.md.

Revisions

• 26 August 2026 First published, from the first recorded run of scripts/capture-weight.mjs.

This page is revised in place rather than replaced, so its address does not change.