The weight of a web page

Nobody sets out to build a 12MB homepage. It happens one reasonable decision at a time: a nice hero image, a second weight of the display face, a video that loops, an embed.

Here is roughly where the weight goes on a design-led site, and what each one is worth.

Images are 80 percent of the problem

A single uncompressed hero PNG can outweigh every other asset on the page combined. We have taken a 4.7MB PNG down to 140KB of WebP with no visible difference at any size a browser will actually display.

The rules are boring and they work. WebP or AVIF, never PNG for photography. Cap the long edge at around 2000px unless you have a reason. Set width and height so nothing reflows. Lazy-load everything below the fold and, crucially, do not lazy-load the hero.

Fonts are the sneaky one

Four weights of a variable face across two subsets is a megabyte before you have written a word. Most sites need two weights and Latin.

Subset aggressively, self-host, use font-display swap, and preload only the one face that renders the first screen.

JavaScript is smaller than you think, until it is not

On a static content site, our own scripts total a few kilobytes: a scroll observer, a counter, a menu toggle. The danger is never the code you write. It is the analytics tag, the chat widget and the embedded map that arrive together at 400KB and block the main thread while they negotiate.

Every third-party script should have to justify itself in a sentence to somebody who is annoyed.

What is worth paying for

Not everything should be shrunk. A large, sharp, beautiful image at the top of a portfolio is the product. Spend the budget there deliberately, then be ruthless everywhere else so you can afford it.

That is the whole discipline: know what the page is for, and make everything that is not that cheap.