A fast site is not a light site

The confusion is common, including among experienced technical teams: page weight gets optimised as though weight were performance. It is one factor, often the most visible one, rarely the decisive one. A 400 kilobyte site can feel slow, and a two megabyte site can feel immediate.

What a visitor actually measures

Nobody perceives kilobytes. People perceive three things: the moment something appears, the moment the essential becomes readable, and how the site reacts when they touch it. Modern metrics translate those three perceptions, and none of them is a weight.

The rendering of the largest visible element depends mostly on the request chain leading to that element. An 80 kilobyte image discovered after four hops, the document, the stylesheet, a script, an API call, arrives later than a 300 kilobyte image declared in the initial document. The weight changed by a factor of four. The order of arrival changed rank.

Responsiveness to interaction does not depend on the network at all. It depends on the browser's main thread. A 30 kilobyte analytics script that blocks that thread for 300 milliseconds degrades the experience more than a 200 kilobyte typeface loaded in parallel.

Three cases from this year

A 380 kilobyte brochure site, judged slow. Every image was lazy-loaded, including the one at the top of the page. The browser could not discover it before the observation script ran. Removing the deferral on that single image gained close to 900 milliseconds on the main render, without changing a single byte of total weight.

A 2.1 megabyte catalogue, judged instant. The initial document carried the text, the structure and reserved dimensions for every visual. The rest arrived afterwards, never displacing anything already on screen. The visitor was reading during the load, so they did not see it.

An internal application cut by 40 per cent, with no perceived gain. The work had targeted dependencies loaded after the first screen. We had optimised what nobody was waiting for.

The useful question, asked first

Before cutting anything, we map the critical chain: the ordered list of resources required for the first useful screen, each with the moment the browser can discover it. That list fits on one sheet. It almost always points at the two or three interventions that matter.

The gains then come from a small number of moves:

1. Declare critical resources early, in the initial document, rather than having a script discover them.

2. Reserve space for elements that will arrive later, so nothing shifts under the reader's eyes.

3. Move off the main thread everything that has no business being there, in particular audience measurement and third-party widgets.

4. Serve from a point of presence close to the visitor, with a cache whose invalidation you control.

5. Then trim, but only what sits on the critical chain and nothing else.

What trimming can still do

None of the above says weight is irrelevant. On a constrained mobile network, in an area with patchy coverage, every extra hundred kilobytes is paid for. A visitor on a capped plan watches their usage. And a heavy site is almost always the symptom of something else: a badly chosen dependency, an obsolete image format, a component that ships an entire runtime to display three lines.

Trimming is therefore a good health indicator. It is not an end in itself, and mistaking it for performance leads to long projects whose results visitors never feel.

Our working rule

We make no weight commitments in our contracts. We commit to the three perception metrics, measured on the pages that actually receive traffic, on hardware comparable to our visitors' rather than on our own workstations. It is harder to hold to. It is the only promise that matches what someone feels when the page opens.