The Payload-to-Scaffolding Ratio
Open the network panel on any article and there's a number in the corner: total bytes transferred. That's not the number you'd reach for if someone asked how much of this trip was actually the thing you came for.
"The web is bloated" has been a complaint for well over a decade, and it has always stayed at the level of a feeling. Pages feel heavier, scrolling feels janky, the spinner takes longer than it used to. Nobody attaches a number to it because the complaint never specifies the denominator. Bloated relative to what? Relative to some year in the past, usually, which is nostalgia dressed as measurement.
The fix is to name the two quantities separately and divide one by the other. Payload is the part of the page a human being was actually sent there to receive: the article body, the headline, the inline images and video, maybe a caption. Scaffolding is everything else that has to ship for the payload to render and for the site to function as a business: the framework runtime, the CSS, the web fonts, the consent banner, the chat widget, the ad tags, the analytics beacons, the hydration script that exists only to make the static HTML interactive after the fact. You can get a rough payload figure by stripping the DOM down to the article body and its media and summing those bytes. Divide that by total transfer rather than by scaffolding alone: same two quantities, but payload's share of the whole reads as a percentage and the browser already reports the denominator for you. It's not exact and it doesn't need to be. A working estimate, taken consistently, is enough to watch move.
Run that math on an ordinary article page and the shape of the answer is usually not close. A couple thousand words of text and a hero image might account for a few hundred kilobytes. The page carrying them might be several megabytes. The ratio isn't 90 percent scaffolding versus 10 percent payload as some universal constant, but it's routinely lopsided enough that stating the actual fraction out loud reads as an accusation, even though it's just arithmetic.
The reason this is worth computing rather than feeling is that scaffolding grows by additions nobody individually notices. A new analytics vendor is fifteen kilobytes. A chat widget is a hundred. A second consent-management platform layered on top of the first because legal wanted redundancy is another fifty. Each one, reviewed on its own merits by whoever shipped it, is defensible and small. None of them, alone, moves a page from fast to slow. But the ratio has no memory of individual justifications, only of the sum, and a site's own payload-to-scaffolding number, tracked across its history, would show a line that mostly goes one direction regardless of what the content itself was doing that year.
The obvious objection is that bandwidth and storage are cheap now, so arguing about kilobytes is fighting the last decade's war. That objection answers a cost question nobody asked. The ratio isn't about what the transfer costs; it's about what fraction of what was sent was meant to be read versus meant to make the sending possible, profitable, or trackable. Those are different things even when both are cheap.
None of this means scaffolding is illegitimate. Rendering needs code, styling needs CSS, accessibility needs markup that has no content of its own, and a site that wants to survive needs some way to measure whether anyone showed up. A ratio of zero scaffolding is not the goal, and nobody should feel caught out by a number that isn't 100. What's missing isn't restraint, it's the habit of computing the fraction at all, so that the thing everyone already senses has a line you can actually watch instead of a mood you can only describe.
The number worth publishing isn't a page's ratio on a given day. It's the shape of that ratio's line over the life of the site.