I reduced the size of my ridiculously large (123 kB) home page

The other day I was reading Dan Luu's post on speeding up his site by 50x. Not bad, Dan, I thought. But as someone who is essentially running a hand coded static website (generated by my home made static site generator) I thought I'd have him beat in terms of page size. Even with a bit of styling!

I totally didn't. And it was never even close.

Nevertheless, when I loaded up the network tab of dev tools, I was horrified to see that my home page had ballooned to 123 kB. That might not seem like much. To someone who cares about minimising the footprint of their website, it is. Contrary to Dan, who looks at user engagement to see if his efforts have yielded positive results, I optimise for a single user: myself.

More often than you'd think, I find myself questioning why I even go through the effort of keeping this site accessible online at all. Although I know that ‘someone, sometimes’ will read something I post, in my head there are nobody else besides myself and a million bots keeping up with what's happening here. Simply keeping it locally available would be sufficient for myself 99 days out of a 100.

The answer as to why online, then, is that on that hundredth day, it is practical to be able to access it online. I also can't deny that I enjoy the odd email from someone who's read something I posted. Which, as it happens, also tends to happen about every hundred days. Lastly, I must admit that the idea of the Internet Archive capturing what I write and making it accessible a while beyond my meagre existence is also appealing in some odd way. We'll see who goes first!

All this to say that, from a strictly practical point of view, this site doesn't really necessitate being online at all. The fact that it is is pure frivolity. That in mind, I at least owe it to myself (‘I am Jack's guilty conscience’) to at least try to minimize its footprint.

Needless to say, this required my immediate attention.

Identifying the bloat

My first task was identifying the causes of the bloat. Upon looking at the network tab of my browser, I immediately spotted a few outliers that were causing the document size to swell to obscene proportions. Common for all of them? They were images.

Profile picture

The intro section of my home page features a small photograph of myself. I originally added this as an element to have a profile picture on the Indieweb Webring¹. As I liked how it added a bit of contrast to the text heavy page, I decided to keep it. The only problem was the image file's ginormous size. For some reason I at some point concluded that ‘60 kB is alright for a stamp sized image’ at some point — presumably back when the front page still came it at below 100 kB.

Due to the changes and additions I've made to the site the last couple of years, that was no longer the case. And the size of this little photo was a main offender.

I took to my favourite image editing tool, Preview and used all the downsizing tricks in my quiver. I halved the dimensions (to match what I was displaying on the site), switched the format from PNG to JPG and turned the image quality down from a ridiculous ‘best’ to something much closer to a far more reasonable ‘lowest’.

The result? A new JPG image file that is only 4 kB. That equates a 93% reduction in file size. Success!

Only one downside. The compression entirely removed the ‘dithered’ effect. You can compare the JPG to the original PNG to see the difference for yourself. This annoyed me. So I threw the problem to my LLM robot servant.² ‘What's the smallest storage size we can get this image down to while keeping it visually indistinct to the human eye?’

The solution was the modern AVIF image format. And for retina ready screens the file size was reduced to 16 kB. Not quite the 93% reduction, but a 73% reduction for the exact same visual appearance is something. I also made a separate file that's served to non-retina screens, where there will be no visual distinction between this and the original, that came in at only 2 kB. And, if you're on an old browser, or one that for some reason doesn't support AVIF, the JPG file is served.

This whole process has me thinking that it's probably worthwhile thinking about building functionality for converting all images in content to AVIF. A project for another day.

Book cover icons

When I tweaked the front page back in May, I wrote:

To spruce it up a little, I decided to reuse the icons from the workout log on the workout log entries. With that little visual in place, it was a short order to just reuse miniature versions of the book covers from the books I'm reading to add a little bit of colour there as well.

The problem was that I wasn't actually using miniature versions of the book covers. I was using the full sized book cover images from my reading log and simply reducing the display size. Mangling the aspect ratio while doing so. It looked… OK, as long as you didn't squint and try to see what was actually being shown. The bigger problem, of course, was that I was spending nearly 10 kB per entry ‘to add a little bit of colour’.

Ridiculous!

My first impulse was to scale down the image and make the aspect ratio square. So that's what I did. But I didn't like the way it looked. It was just a tiny, little puddle of colour. As if I'd thrown a bunch of paint on top of a little sheet of paper and let it mix. ‘Some separation between the colours would be nicer’ I thought to myself. And that got me thinking about the pixelated effect that was really popular among wannabe ‘graphic designers’ (myself) about two and a half decades back.

Next step was opening up GIMP and experiment a little. After some trial and error, I settled on the following:

The ‘pixels’ are fairly large in size at 7 x 7 pixels per square, for a total of 4 x 4 squares in the 28 x 28 pixel canvas. (That's a lot of numbers!) I liked the visual appearance of this approach. It feels like a little nod to my attempts of saving space and bandwidth in terms of how it looks, while adhering to the original idea to ‘add a little bit of colour’ even better than the original solution.

To finish off, I used my LLM to build a small script that relies on pillow to generate these image files (as SVGs) for the books I'm currently reading when my static site generator builds my website. What a world we live in, where this step is almost an afterthought.

These new illustration images are only around 1.2 kB per image. As opposed to around 10 kB for the original book cover images I used to show. That's an 88% reduction. And, in my very humble opinion, it looks much cooler as well!

Unused CSS

My site generator is super simple. By design. It's the only way someone like myself can hope to remember how it all works. In terms of styling, it pulls a style.css file and inserts it into the head of every HTML page it generates. It works great, because it means I have all my CSS in a single file.

The downside is that, as I've added new sections to the site the past couple of years (looking at you, workout log), the style file has grown. A lot! Upon inspection, I found that styling accounting for 24 kB out of the front page's total document size of 33 kB. 72% of the entire document was styling. Most of it completely superfluous on the front page.

The time had come that simple was no longer good enough. It had to redo the logic to reduce the amount of unused CSS included in each page.

As already mentioned, I need to keep things as simple as possible to be able to keep up with how stuff works. Given that this is my personal setup, made for myself alone, my understanding it is a priority. So I went with the simplest solution I could think of:

• One global stylesheet that gets inserted into all pages
• One template specific stylesheet that gets inserted into pages with that template

My setup currently consists of nine templates³. That means nine new style files to maintain. But, as I hypothesised that the global stylesheet (and my front page as a result) would be at least halved in size, I was convinced it would be worth it. For once, I had the pleasure of being right.

Much of the styling bloat was related to various minutiae in the workout log. Getting that into its own, dedicated template significantly reduced the size of the style section of the pages outside of the workout log. The style section of the front page is now 8 kB. A 67% reduction!

As an aside, the LLM I was using tried to convince me to go with a more convoluted, three tier approach for ‘more size reductions’ when I was implementing this. The proposed solution was a bit of a halfway house between the simple approach I devised myself and the most efficient (and most complex) option of pulling only the relevant style definitions per page.

Upon reviewing the suggestion, I decided that the marginal gains were not worth it. I want to simplest possible solution to maintain. To the extent that when I come back in two years time to tweak some styling without having to expend precious brain power (my supply is severely limited) trying to recollect how I would go about doing that again.

The numbers

The whopping 123 kB size of the front page started this all. With the changes I've detailed here I've brought that down to 37 kB.⁴ A 70% reduction. At the price of exactly no noticeable downgrades to the user experience.

I should probably look to apply some of what I've learned here to the rest of the site as well. Incorporating an image converter into my site build and serving AVIF files all around would be a good place to start. One for ToDo.md and then we'll so what happens after that.