Jeeeeeekyll? No, Hugo!

Software
Page content

As I was writing about my transition from WordPress to Jekyll, I knew I had to prepare for another change.

From a technical point of view, Jekyll is a fantastic platform: it is easy to program, has impeccable documentation, and works perfectly during the development phase, with a limited number of pages and test posts. But, as I experienced firsthand, when Jekyll is asked to handle a real site with hundreds of posts, performance drops dramatically and response times become unbearably slow (and quite embarrassing, too).

In the late ’90s, it was normal to wait several seconds for a webpage to load.1 But today, we’re used to pages that load instantly, so having to wait three or four seconds is unacceptable.

A high price to pay

Before I started working on the new site, I was well aware that Jekyll was slow. However, this slowness was always attributed to the site generation phase, which is performed sporadically and can be automated. And that was exactly what happened: during development, with a few dozen posts, I could regenerate the site in 10–20 seconds, quite annoying, but not dramatic; now it takes 15 minutes to regenerate the entire melabit.com.

What I didn’t know was that the generated site would also suffer from the same problem, which became evident as soon as I finished the development phase and started working with all the posts.

At that point, I was still convinced that optimizing the code and images and applying an aggressive caching would mitigate the issue. And in any case, I had gone too far to turn back. However, I soon realized that this strategy wasn’t enough, and that a radical rethink was necessary. So I started looking around.

Alternatives

Static site generators are like Linux distributions: there are too many of them, and in most cases it’s hard to understand why they even exist. At the moment, Jamstack lists 366 of them, while Static Site Generators counts nearly 500. Most have been abandoned, maybe because nobody was using them, or because the developer lost interest in continuing development. Let’s say the interesting ones are a dozen or so, maybe a few more.

Among these, I considered Bridgetown (very briefly, I admit), which is derived from Jekyll and therefore, at first glance, seemed like a natural evolution. However, I realised that few people use it, there are few plugins and even fewer themes. If Bridgetown is derived from Jekyll, how could I be sure that it didn’t suffer from the same slowness issue? Better to stay away and stick with the original.

Another candidate was Middleman, which is developed in Ruby like Jekyll. But Middleman is designed to generate plain websites, and you need a specific extension to make it support typical blog features, such as lists, taxonomies, feeds and comments. Also, the templating language is ERB (Embedded Ruby), which is a sensible choice since it’s integrated within Ruby. However, it meant having to relearn everything from scratch.

Long story short: in the end, the only serious candidate was… the good old Hugo.

Looking for speed

Many years ago, I wrote a post about Hugo, finding it interesting, but crippled by documentation that calling poor was being generous.2

However, its quality is not in question. Unsurprisingly, Hugo consistently ranks at the top of all the charts evaluating the quality of static site generators, just like Jekyll.

And Hugo has a real ace up its sleeve: it’s fast. In fact, it’s blazingly fast!

I can’t say whether Hugo is truly the world’s fastest framework for building websites, as claimed in the slogan at the top of its homepage. However, I have verified firsthand that Hugo can generate this entire site in under a minute, 15 times faster than Jekyll. Most importantly, the generated site is fast and responsive, exactly as you would expect from a modern website. That puts everything else in the background.

Hugo

So starting today, melabit.com is moving to Hugo, with a new design3 and trying to keep all the features of the Jekyll-based version. The first of these is the [Comma-based commenting system]https://melabit.com/en/2025/03/05/from-melabit-to-melabit-managing-comments-with-jekyll/), which after the transplant worked practically on the first try.

The permalinks have changed and now explicitly indicate the language of the post, which is a more rational approach. The feed has changed too. For now it’s the old RSS, but at some point I’ll check whether it’s possible to add ATOM.

Right now, the search function is based on Google, and will not work until the site is indexed again. Pagination needs to be revised, as does the logic that shows the featured post in the list of all posts. But these details can be sorted out later.

Because of how my mind works, I’d love to go into the details of how I modified Hugo and the chosen theme, but I’m afraid it would be boring, in particular after all the very detailed (but now almost useless) posts I wrote about Jekyll. I’ll think it over. In the meantime, if anyone is interested in knowing more, feel free to say so in the comments.

– Image generated by Google Gemini.

  1. But you could at least distract yourself by watching the images appear one line at a time on the screen… 😂 ↩︎

  2. Not much has changed since then. One of the (few) posts I can recommend without reservation is this one on managing context and variables in Hugo. It’s a very technical read, but essential for learning the basics needed to modify and extend Hugo. ↩︎

  3. I’m not thrilled with the design, but it’s the best I’ve been able to come up with so far. ↩︎