An Introduction to Hugo and Static Site Generators
Let’s talk about static site generators. In this post we’ll learn what they are, how they differ from a traditional dynamic CMS and why you should consider one for your next website.
It’s good to start by saying that static sites are nothing new, way back in the mid 90’s and until the turn of the century static sites were the norm. What do I mean by static? Well there was no content management system, no database and no logic or functions - each and every page was created by entering text into a basic HTML document. Tedious work, which ultimately allowed CMS’s like WordPress to become so popular.
Static site generators have extended the traditional way of writing static HTML by mimicking a server-side framework, like WordPress. Its toolset includes templates, partials, variables, functions and logic. Where they differ from dynamic sites is with their speed of delivery, reliability, cost of hosting and security.
To date there are two main static site generators to choose from, each different in their approach, they are Jekyll and Hugo. Personally I choose to work with Hugo due to its faster render time and better documentation, but they both aim to do the same thing - which is output static HTML files. This very site is built using Hugo and takes approximately 10 milliseconds to build!
How static site generators work
To understand why the technology is becoming favoured over a dynamic CMS we first have to learn how a static site generator works and how it compares to a traditional dynamic site. In these examples we’ll assume we’re referring to a website built using WordPress - a popular PHP based dynamic CMS.
How a dynamic CMS renders a web page
When a user enters a URL into their browser a request is made to the server, let’s assume it’s for an “about page”. The server talks to the database and requests the content for the page (text and images), the templating engine then identifies which page template this content should be displayed on, in this example the “about page template”. With these steps complete the about page is then built (in real-time) and delivered to the users browser. It’s a complicated process and a reason why most dynamic sites are slow to load and expensive to host.
How a static site generator renders a web page
Like WordPress a static site generator has a templating engine, variables, partials, logic and functions. A developer will create the necessary template pages to render your content and the author will write this content in markdown. When changes have been made an instruction is sent to the static site generator to “build” the site, which takes milliseconds. The output is a collection of static HTML files which are then uploaded to your server. This can be automated through a process called continuous integration / deployment, so when a change is made a trigger is sent to re-build your site and push the changed files to your server.
Now let’s compare the above example with a site built by a static site generator. When a user requests a page there is no database or templating lookup and no page rendering, just a simple return of the pre-rendered HTML page (and other supporting assets). It’s lightning fast, isn’t resource heavy and capable of handling tens of thousands of hits per minute.
The benefits of going Static
Static is not for everyone and I wouldn’t recommend such technology to those that require complex functionality. But for the majority of small brochure sites it’s a worthwhile consideration. The benefits include:
There’s no server rendering, just simple static HTML files being returned, so your site will fly. My previous WordPress site went from an average of 3 seconds load time to 0.7 seconds running on Hugo. My GTMetrix score jumped to an “A rank”, a huge improvement and great for SEO! For further improvements you can take advantage of a CDN like CloudFlare to cache your pages and assets.
Backups recovery and deployment
The majority of static sites follow a similar workflow, they’re developed locally and committed into version control and on each commit they are then automatically deployed to a live server. This workflow has two benefits, firstly each and every change is versioned, if you make a mistake or change your mind you can revert to a previous commit and redeploy your site within seconds. Secondly version control acts as a backup, there’s no need to run a plugin or subscribe to an expensive third party solution like you would if you were running WordPress, it’s all part of your existing workflow.
One of the major pains with WordPress development is collaboration and this is mainly due to the database. For a developer to make changes to a traditional WordPress site they must take a clone of the site, make the changes and then overwrite the existing site, during which time the live site can not be worked on as it would cause database merge conflicts. As there is no database to manage on a static site and the codebase is in version control, multiple developers and content authors can work on the same site in tandem with no downtime.
We’ve already touched on how complex and resource heavy rendering a dynamic site can be, which is why you get what you pay for in terms of hosting. For a decent virtual private server with automatic backups you can expect to pay on average £30 per month, more so if it’s a high traffic site or you’re looking to use a managed WordPress host. In comparison, serving static HTML files from a server can be accomplished with a low cost shared host, which can be as low as £5 per month and by taking advantage of a CDN like CloudFlare you’ll see further improvements in delivery speed.
Solutions for traditional functionality
There’s a misconception that going static will get in the way of traditional workflows and functionality and yes, there are a few limitations. For the majority of cases though, solutions exist to provide the expedited functionality whilst allowing all the benefits you’d expect from going static.
Content creation and management
A static site has no CMS and no backend, which is great for speed and security. But not all authors are technically minded, confident writing in markdown or committing their changes to Git. These users require a content management system and many third party solutions available exist. They are known as a “headless or static CMS”. For Hugo there’s Forestry.io, Jekyll sites can make use of both CloudCannon and Siteleaf.
Site searching and content filtering
If your using a web server that can run PHP (and the majority can). Including contact forms in your static site is no more extra work than if we were using a traditional dynamic site. We simply create the form frontend, required processing PHP logic and link the two via a standard AJAX call.
The limitations of going static
As I’ve mentioned, the static approach is not for everyone and careful consideration should be made to ensure your needs are well suited to this technology. For the right site the static approach excels, but for some uses it has its limitations.
A static site would not be recommended for those that are looking for an e-commerce solution. The core functionality of these sites require complex PHP logic to perform essential tasks, which simply can not be achieved in a static environment. That being said, some workarounds are beginning to emerge, including using Shopify “Buy buttons” and Snipcart
User portals and forums
Static sites fall short for sites that require some form of user interaction, be it the creation of an account or a community forum. Usually these types of sites require some form of data persistence, which is usually achieved using a database and server-side logic to process and manipulate the data. As a static site operates independently of a database it is not possible to create a site of this scale or scope using a static site generator.
Seasoned WordPress users may be used to being able to extend functionality of their site through the use of a plugin. This is not currently doable for static sites. If you wanted to enable certain bespoke functionality it would require the services of a developer to implement. This may be an issue for those who are trying to reduce costs by relying on open-source software.
Make the switch to Hugo
WordPress is great, but I think for most clients I meet it’s overkill. If you’re currently tied to WordPress or have a new project that you feel would benefit from being built on Hugo or Jekyll, consider making the switch, I don’t think you’ll regret it. I’m available to take on new Hugo and Jekyll builds and the conversion of existing WordPress sites to this new technology. For all enquiries please get in touch.
Thanks for reading, that’s all folks!