WordPress and Hugo are two radically different tools you can use to create and manage your personal blog / portfolio / whatever website.

WordPress is a CMS platform, an web hosted application, where you can manage, write, update and post content of all kinds (mostly pages and posts). Hugo is a static site generator, which is a tool to create raw HTML/JS/CSS websites to publish on the internet – no web hosted application involved.

In simpler terms, WordPress is a bit like Word, you edit your posts / pages directly in a graphical tool. In contrast Hugo treats websites like Software, but instead of converting source code into applications you convert markdown files into HTML.

Unsurprisingly most people will prefer the simplicity of a tool like WordPress, but there is fondness for Hugo-like static website generators among IT people (e.g. Software developer). As a software developer one could expect me to choose Hugo (or an equivalent) over WordPress. But I made the decision to move back to WordPress. Here are some of the reasons.

Static sites are not significantly faster

Static websites generated by Hugo are on paper faster than CMS like WordPress. In practice the difference isn’t that big.

WP-beginner, a WordPress website dedicated to WordPress support loads its media heavy pages in about 200 ms. Gentoo Linux official website, static site generated by Jekyll (an alternative to Hugo) loaded in under 100ms. In both cases the load time in under 250 ms.

For my personal website, my former blog hosted on Github Pages generated by Pelican (yet another Hugo alternative) would load in 150 ms and my new self-hosted WordPress blog loads in 250 ms according to the Uptime Robot monitoring system.

WordPress is still fast enough. It is because of caching. Most well configured websites will use some of caching, which is the digital equivalent of not doing the same work more than once but instead keep a copy of the final result (with the caveat that in digital world you need throw away the cached result sometimes). This means in practice a well configured website will usually behave like a static site for most pages.

Web content is not software

Websites are not software. Most static website generators encourage a development workflow. This means all of the following : editing configuration files, compiling markdown pages into HTML, using Git to commit and push your page to a platform like Github and automate delivery through a CI/CD pipeline.

There are use cases for managing websites these ways (e.g. if you do a lot of automated posts). Writing a page in Markdown and then checking how it renders in your browser is a bit rough. With WordPress with a click of a button you can check how things render on mobile, add alternate text to images, … You don’t have to worry about Github actions failing. Basically you focus on what you publish and little less.

WordPress has a better ecosystem

After reviewing themes for Hugo and for WordPress I realised there is notable cultural difference between the two ecosystem. Not only I found Wordpres to have a better themes, they were designed to enable easy customisation for end users easy. One example of this is changing the accent colours. WordPress themes can be tweaked from the UI with a colour picker. Hugo themes can be complex. In one case the CSS file governing the colour theme was generated by a Node.js program. I haven’t found a general pattern in how theme are managed in Hugo. I’d rather not bother learning a couple of different ways to tweak colours when evaluating themes.

Another strength of the WordPress ecosystem is its extensibility through plugins. Here is a couple of things I do with WordPress. First I gather statistics on many visits I get and which page (including non existing ones) are targetted. People targetting non existing pages could be symptoms on a link somewhere on the internet to a non longer existing page. You can take advantage of this with another tool I use call Redirections. I use Redirections to make sure the URLs (no matter how old they are) are still valid. No need to edit nginx configs and needless to say this wouldn’t be easy with most static site hosting solutions.

Furthermore extending beyond a simple site is easy with WordPress, but tricky with static websites. Let’s say you want to start an e-commerce site with SEOs and statistics. With WordPress you have plugins for that directly built-in, but with static sites you have to create hooks to third party services (which can be still used with WordPress so you get the best of both worlds).

Other considerations

Always check the fine print. Just because static site hosting is free doesn’t mean there aren’t caveats. Let’s say you do not explicitly agree to allow AI to be trained on your content. You should know many free static hosting websites (e.g. Github pages, Netlify) will have you agree to AI training on your content in their terms and conditions.

Cyber-security is sometimes the reason why static site generation is preferred. The idea here is that a static site does not require a database and code (usually PHP) to generate pages when live. If you self-host then a static site will have fewer moving parts compared to WordPress (self-hosted or not). However if you use a service like Github pages this is no longer true. When using Github pages chances are you are using third party Github actions which could be a source of cyber security concerns, not to mention all of the good practices to follow with authentication permissions, repository visibility, SSH keys, …