The twelve-megabyte trophy

There is a specific kind of website that wins design awards and fails everybody who is not a judge. You know it when you meet it. Something arrives on your screen after a long pause. A cursor becomes a circle. Text assembles itself letter by letter with a delay calibrated for a machine with a discrete GPU. Scrolling is smooth in a way that scrolling is not supposed to be smooth, because scrolling has been taken away from you and replaced with an animation controlled by JavaScript.

On a high-spec laptop with fibre broadband, it is genuinely wonderful. On a mid-range Android phone on a train, it is a blank screen followed by a jolt.

We are not against ambition. We build sites with heavy craft in them. But the profession has developed a real blind spot, and it is worth being precise about the mechanics of it rather than just complaining that things feel slow.

Why the pattern persists

The incentive structure explains almost all of it. A design award is judged by people who are, almost by definition, working on excellent hardware with excellent connections, often on a desktop, usually with a warm cache by the time they are seriously evaluating. The gallery thumbnail is a video. The screenshot in the case study is a render.

Meanwhile the design team building the site develops on a workstation, previews on the same workstation, and demos to a client who has been sent a link on a laptop. Nobody in the chain, at any point, experiences the site the way a real visitor will. The feedback loop that would catch the problem simply does not exist, so the weight accumulates invisibly, one beautiful decision at a time.

Where the megabytes actually come from

When we audit a heavy site, the payload is almost never one catastrophic mistake. It is five reasonable ones.

The hero video. Somebody exported a 20-second loop at 1080p and dropped it in as an MP4. It is 9MB. It is also playing behind text, at 30% opacity, in a container 900px wide. Encoded properly at the size it is actually displayed, and with a still frame as the poster, the same effect costs a fraction of that.

The animation library stack. A scroll library, an easing library, a physics library, a 3D library — each brought in for one effect, each pulled in whole because tree-shaking was never configured. Four hundred kilobytes of JavaScript before a single line of the site's own code has executed.

Fonts. Six weights of a variable font, loaded as separate static files, none subset, all of them blocking. A font that has been subsetted to the Latin range and loaded as a single variable file with a sensible font-display policy is a rounding error by comparison. Loaded carelessly, typography becomes the single largest cause of layout shift on the web.

Unoptimised imagery. PNGs where AVIF would do. A retina asset served to a phone. No width and height attributes, so every image is a small earthquake when it lands.

The third-party tail. Analytics, a heatmap recorder, a chat widget, a consent manager, a font host, a tag manager loading three more things you have never audited. Individually defensible. Collectively, often larger than everything the design team shipped.

Nobody sets out to build a twelve-megabyte website. They build twelve one-megabyte decisions and never add them up.

The measurements that matter

Lighthouse is a useful tool and an unreliable master. Run it on your desktop over a fast connection and it will tell you comfortable lies. The numbers we care about, in order:

Largest Contentful Paint on a throttled mobile profile. Not desktop. Slow 4G, 4× CPU throttle. This is the closest simulation of the person you are actually designing for. Under 2.5 seconds or it needs work.

Cumulative Layout Shift. The most under-rated metric in design because it is the one designers can most easily cause. Anything above 0.1 is visible to a human being as a flinch. Fonts, images without dimensions, injected banners and late-loading embeds account for nearly all of it.

Interaction to Next Paint. How long between a tap and something happening. Heavy scroll handlers and unthrottled mousemove listeners destroy this quietly. It is the metric that separates a site that *is* fast from a site that merely *loaded* fast.

Total blocking time on the main thread. If the main thread is saturated parsing your animation stack, the page can be visually complete and completely dead to the touch.

Doing the ambitious version anyway

None of this is an argument for building plain websites. It is an argument for spending your budget deliberately. A performance budget works exactly like a materials budget in any other design discipline: you get a fixed allowance and you decide what deserves it.

Ours is straightforward. Under 200KB of JavaScript on first load, compressed. One variable font family, subset, two families maximum. No video above the fold unless the video *is* the content. Everything below the fold loads on intersection. Any animation that cannot be expressed as a transform or an opacity needs a written justification, because those are the only two properties the browser can animate without repainting.

The constraint is generative rather than limiting. When you cannot afford a WebGL fluid simulation, you are forced to find the idea — and the idea, being an idea, is what a jury remembers anyway. Some of the most striking work of the last few years is close to weightless: typography at enormous scale, a monochrome palette, hard cuts, one moment of genuine surprise. That entire vocabulary costs kilobytes.

The device you should be testing on

Buy the cheapest Android phone currently sold in your primary market. Put it on the desk next to your monitor. Load every build on it.

It is the single most effective intervention we have ever made to our own process, and it costs less than one day of studio time. The laptop lies to you constantly and with great enthusiasm. The cheap phone never does. Within a week, arguments about whether an interaction is "smooth enough" stop being arguments about taste and start being questions with an answer that anyone in the room can check.

The uncomfortable conclusion

If your site wins an award and cannot be opened on a four-year-old handset in a train tunnel, you have not built an excellent website. You have built an excellent demo of a website, and the jury has evaluated the demo.

The good news is that the two goals are not in tension nearly as often as the industry pretends. Almost every heavy site we have audited could shed 70% of its weight without a single visible change to the design. The weight was never the point. It was just never measured.