Skip to page content

Premature Optimisation

When I was starting on this site, I tried looking for pre-built themes that I could quickly modify to suit my own tastes. In the end, I was not fully satisfied with any that I found, and decided to roll my own. Having only lightly dabbled in HTML+CSS, the Hugo documentation and MDN web docs quickly became my best friends.

From the very beginning, I hoped to make my site as lightweight as reasonable. Thus, I purposely chose to avoid all unnecessary JavaScript — turns out I needed none — and utilise system default fonts. These choices gave me immediate, big wins.

Falling into the trap #

Fast-forward a couple of weeks, and my site was probably 80% done. But following that, I fell into the unfortunate trap of obsessing over unnecessary details:

  • How can I reduce the number of lines in my style sheets?
  • Is it possible to only send one style sheet?
  • Should I shorten the names of all my HTML element IDs and classes?
  • Can I set the appropriate HTTP headers to maximise caching of content that is not expected to change?
  • What can I do to reduce HTTP header bloat?

Pursuing these micro-optimisations gave me a sense of achievement, letting me feel like I am going above and beyond in squeezing out every last drop of performance from my site. But after the fact, I have come to the realisation that these are hardly useful for a small, personal blog.

Premature optimization is the root of all evil — Donald Knuth1

And indeed, the time spent obsessing over these small details was almost definitely not worth the paltry (if any) resultant performance gain. After all, when adding a single JPEG image brings with it ~150 KB of additional payload, saving ~2 KB hardly seems to matter.

Avoiding the trap #

Looking back, I feel that a major reason for my premature optimisation is that I lost track of what my site is supposed to be: my personal corner of the Internet. Being a small platform-for-one, this is no top-500 website that sees thousands of visitors a minute, and many of those “SEO best practices” are just not necessary for a simple static blog.

Another reason for my premature optimisation was due to me trying to rationalise delaying going live: by “working on improving” my site, I could tell myself that it is okay to not go public yet. Personally, this was due to me being uncertain if my site is good enough, though there could be many other reasons one would try to (unnecessarily) delay going live.

Here, I feel that the best strategy is to just carry on: a product will never be perfect, and there will almost definitely be some edge case in the real world that we failed to micro-optimise for.

Finally, I actually enjoyed obsessing over the small details: it made me feel like I am making something really special, something better than what is out there. In my case, I can afford the time spent fussing over the small details, since this is done in my own free time. But for non-hobby work, developers may not be able to afford wasting time chasing down trivial gains.

Summary #

In the end, I actually do not regret micro-optimising my site. I believe that I have learnt a fair deal through this experience, and that is definitely valuable. Nonetheless, I also believe it is important to recognise when we start worrying about unnecessary optimisations, and to prevent ourselves from falling into the trap.


  1. From Knuth’s book The Art of Computer Programming. ↩︎