Home > Blog > The 512kb Club: the web on a diet
Recently I found out about something called the 512kb Club. It’s a collection of websites whose entire size, when transmitted from server to browser, is less or equal to 512 kilobytes uncompressed. That is quite the prospect. Similarly, there is also a 1MB Club. Self-imposing this limit is far from ascetic however, as I will reveal below.
According to the clubs website the website for the New York Times has grown to over 15 megabytes! But how bad could this be, if it is even bad at all?
Some research is needed
I took it upon myself to find what could be the biggest website in the world. Some oddballs that I found were the self-proclaimed tallest website and one that grows with every visitor. The largest I found was Gfycat (~32MB) which is not odd, considering their content is exclusively animated images. Another bad offender was blizzard.com (~17MB.) My website floats around 2-2.5MB depending on what page, which is about on par with the average.
The consequences of this is that websites take longer to load in those parts of the world where internet connections aren’t that fast. It’s also bad for the environment as this data has to be transmitted (more info on this) from often idle (and thus power wasting) servers.
To coin a suitable term: a web footprint.
Not an exercise in minimalism
Anyone can piece together a page with little to no style or images. But that is not the point of the 512kb Club. Minimalism and frugality might be a solution but boring and unusable websites definitely aren’t.
Let’s go back to the days where the IBM PC had 640kb of RAM. Did this limit detract from the usability of the system? No. But inspiring graphics it definitely did not have out of the box, they were achieved through optimization and clever tricks. The hard limit bred innovation.
A 512kb limit does not constrain design as much as one might think. Layouts do not affect transfer size much or at all. FontAwesome also supports stacking icons out of the box, adding another dimension to iconography without adding much size.
WebM, WebP and SVG’s can fill this perceived gap. Cleverer usage of HTML and CSS also helps as using classes and inline styles everywhere adds unnecessary size. Likewise with unnecessary wrapping elements. Unused parts of libraries might be removed through cherry picking functions, SASS or tools like UnCSS. Minifying JavaScript and CSS is now an industry standard, but I still talk to developers that don’t do it with HTML when working statically.
Devils advocate
To provide some counter arguments, perhaps all this is not even needed as long as our SEO and conversion are fine. As technology progresses we don’t have to punish ourselves with endless diets for our software stacks. Bloat is never nice but eliminating the excesses we concern ourselves with here might not even amortise in speed, security and eco-friendliness.
Economically speaking, throwing money against a relatively small problem like a few megabytes isn’t worth it when we can make technology ease the symptoms for us through compression and caching for far less costs.
Core takeaways
The goal of this is obviously to call attention to the fact that all this bloat is just not needed. We can do better. It has certainly piqued my interest and I hope you in return may also get inspired to slim down your web footprint while maintaining your web presence, perhaps by hiring me 🙂
Too cheeky?
Seriously though, the 512kb Club is an admirable effort to call attention to an omnipresent problem. Software bloat persists throughout the computing world and as the web is the future, it is the place to start the diet.