Web Bloat — The Eternal Lament

Let’s wind back — way way back — to the early days of the InterWebs. The year was 1994, and a bunch of us were building out some of the first commercial “web sites”.
(Quotes because a decent chunk of the sales process actually involved explaining WTF was a “web site” was in the first place, why you should care, and just give me the damn money. But that’s a story for another day…

Anyhow, back then we had a limit of 50KB per page. And even that was something that we had spent days — weeks even! — arguing about amongst ourselves. After all, 50KB? That would take forever to load! Also, how could you possible have that much stuff on a page in the first place?
And then you had the other side, whose argument basically could be translated to “As long as it looks good, I don’t give a shit about size”. Of course, yes, there was a bit more about aesthetics, and the integrity of the design, and a whole bunch more.

This argument, as far as I can tell, has been codified into the very fibre of the InterTubes these days, to the point that I don’t think it can be called an anti-pattern anymore . It really is quite ridiculous — some of the bloat is justifiable, but so much of it is just plain dumb, and exists in some kind of lowest common denominator limbo (because…npm I guess?).

Size, of course, is not actually dispositive — it’s load-time that you should actually care about. But, that said, you can’t just keep ramping up the size (2–3MB/page these days?) and not expect to leave eyeballs on the table.

Mind you, it’s not just about eyeballs. Let’s go back again to the early days — when, one of our developers came up with the brilliant idea of having two versions of each “web site” — one with low-rez images, and one with the high-rez (50KB!!) versions. We even had a handy-dandy link on the top of the page that you could click on to change resolutions (Responsive Design circa 1995 ). The thing is, as soon as we deployed it, response times — and customer complaints! — went up! And not just a wee bit, we were getting, like ∞ complaints saying nothing was loading!
After the inevitable panic, and a lot of trouble-shooting, we figured out that thanks to the “low-rez” versions, a lot more people were using our system. Which meant that our web-servers were getting overloaded, and response times fell off the cliff.
(It took forever to figure out what was happing with the web servers because, remember, this was the early days of the internet. Tracking HTTP connection counts and times was basically all about shell wizardry. Seriously.)

The oh-so-painfully learned lesson here, of course, being that page-size isn’t just about customer satisfaction from a “it’s faaaast!” perspective. It can have all sorts of secondary effects on things like cost models, system design, and so on. In short, it can affect your core product assumptions.
So yeah, pay attention to page-size (and response times). Not just because lower response times are good, but also because leaving them high can obscure any number of ancillary issues with your product!