About the author
@catalinmpit is a software engineer, AWS community builder and technical writer based out of London. He’s currently an engineer at TypingDNA, working on applying keystroke dynamics as a means of biometrics authentication.
Check out more of his work on catalins.tech
Looking at websites from a very generic perspective, they can be grouped into two categories:
- Static - Designed once with fixed content.
- Dynamic - Content is almost always changing, connected to a backend entity (a CMS or another service).
From a technical point of view, one of the main differences between static and dynamic is how they deliver the site’s content. The latter generates pages on demand, with every request. Static sites have their pages ready any time. Thus, it’s just a matter of sending those to the visitor’s browser.
Now, what happens if you require something in the middle? Say you want to benefit from static’s advantages while still controlling everything through a CMS. This is where a static site generator (SSG) can come in handy.
What is an SSG?
A static site generator (SSG), as its name suggests, is a set of tools designed for building static websites. This set usually consists of applying data to various templates and generating HTML pages out of them. Data itself can come from markdown files and content management systems (Git-based, headless, etc.).
Why should you consider using one?
One of the most important things to consider when talking about static site generators is security.
When you’re using an SSG, the server which hosts your websites will no longer need to perform various logical operations (e.g. filling templates with dynamic content).
This is because every single asset is pre-generated at build time, so you’re ending up with a bunch of pretty dummy HTML, CSS, JS and media files. Removing the need for connecting to a database to display simple content reduces the attack surface to a bare minimum. This can be a tremendous advantage over soultions such as WordPress, where the CMS version being used can require frequent updating to stay safe.
Another essential aspect is performance. Since the content is ready to go, your server will respond faster. Going a step further and serving everything from a CDN, you’ll be able to make everything even quicker, as your requests will travel shorter distances, free of any other system interaction.
Further, static content can also be easily cached, which adds an even more significant performance boost. Combining all of the points mentioned above will help to decrease loading times and improve your user experience. This is especially handy when your website’s visitors are on a relatively slow internet connection.
Another great benefit is the ease of hosting your website. Since all you have is a folder full of assets, you can easily host it wherever you want, without needing too much configuration.
The only significant consideration is the deployment process if you want to have an automated mechanism. Solutions like Netlify have simplified this process to just a few clicks.
What’s the best static site generator?
Static site generators are around for quite some time now. At the time of writing, there’s are hundreds of options to choose from. So, which one’s best?
Short answer is: it depends.
It all depends on the project you have at hand and the tech stack you’re used to. Are you comfortable in using React? Gatsby and Next.JS are some of the most popular choices. Rather go with Vue? Try Gridsome or Nuxt. Vanilla JS? Go for Eleventy.
My favorite SSG is Eleventy: a lightweight and straightforward solution. It’s framework-free, works with multiple template languages (MD, liquid, njk, moustache & more) and you can fit it within your existing directory structure. Another benefit of Eleventy is that you only need to define your data once (in markdown). After that, it’s available in all the templates (making it a lot faster than working with Gatsby, for example).
Worth mentioning: Most of the SSGs above can be combined with multiple third-party plugins which offer extra functionalities out of the box (e.g. PWA configuration, analytics, lazyloading, etc.).
As a note of caution, adding too much “magic” or customizations to your projects can sometimes snowball into issues that are annoying to debug. For example, you won’t need plugins to add OG meta tags or create a website’s manifest file.
Hopefully this sparked your interest in SSGs or answered some questions you had regarding them. I suggest to go and experience them yourself. Play around and find out what fits you best.
Catalin regularly posts helpful development tips and guides on Twitter. Be sure to follow him at @catalinmpit