Why I've switched to Hugo

I've been running a blog intermittently since 2015 - firstly as a self-coded PHP application, then like a huge number of people, using WordPress

WordPress is great and allows you to create amazing, visually stunning sites with a huge amount of flexibility, but it comes with complexity. As I've used technology more, I've learned to try and choose the simplest option so I wanted to describe what I'm now using to run simonhanmer.com and the reasons for the change.

So why am I switching?

Whilst WordPress is an excellent product, I've decided that due to a number of factors I didn't want to continue using it. Note that whilst I'm pointing the finger at WordPress here, most of the factors would apply to a lot of Blog/CMS applications such as Drupal or Joomla.

After trying out various options, I've switched to Hugo. Hugo takes a different approach to managing a blog - rather than running an application which retrieves content from a database and rendering this on request, Hugo used textfiles to manage content, with the content being formatted using Markdown. Hugo takes that content and uses it to generate static pages (along with a small amount of Javascript to improve user experience), which is then uploaded to online storage such as an FTP site, AWS S3 or GitHub Pages.

Below are some of the factors that influenced my choice.

Infrastructure complexity

To run WordPress, we need a webserver that can run applications, specifically one that can handle PHP. This means that we either need to rely on someone running a secure server, or we need to do that ourself which means ensuring we're patching and updating as appropriate.

We also need a database somewhere, typically MySQL or Postgres and again this means someone hosting the database server.

The risk with the web and database server is that if these are not properly maintained, they might be compromised and content removed, or worse, used to host malware.

Because Hugo generates static HTML pages, there is no need for any of these infrastructure complexity. We just need a way of serving HTML such as an FTP site, or S3 storage from Amazon Web Services.

Wordpress Updates

Not only do we need to keep our infrastructure updated to ensure security, we also need to ensure that the WordPress application is updated regularly - along with any plugins and themes used. As we add more functionality, there are more interlocking pieces that need to be managed.

One particular issue that I've seen is that plugins are no longer actively maintained and over time won't work with the latest version of WordPress, so you need to spend time finding alternatives.

It's true that we do occasionally update the version of Hugo that we use to generate the site, but because we're deploying static pages, the risk of issues is vastly reduced.

Site Footprint

Whilst most hosting packages these days offer a reasonable amount of space, it can't be ignored that running a WordPress site means that you need to host the application along with the blog content. With the base application, plugins and content, my previous site was running at approximately 300Mb - and this was for a handful of pages.

Now that I've switched to Hugo, my site is sitting at just under 5Mb.

Loading Speeds

Whilst I've left this until last, I'd argue that for the readers of my blog, it's probably the most important. To display content, WordPress needs to run a lot of code, querying databases to generate a page and then render it. Before I switched to Hugo, it was taking 4-5 seconds before content was rendered.

Now that I'm using Hugo and it generates the pages beforehand, that initial load and render is rarely above 2 seconds, giving a much improved experience to the reader.