Written by Charlotte Drew and Jack Standbridge
Static sites are making a comeback. Thanks to developments in tooling and templating, static sites have the potential for greater complexity and flexibility, without the need for an unwieldy backend.
The word static is not one that springs to mind when thinking about technological innovation. Surely when we talk about the future, we should be focusing on dynamism and continual forward movement? Certainly, in terms of web development, the concept of a static website might conjure painful thoughts among some developers of individual HTML files laboriously created by hand.
But we've come a long way since ye olde days of the internet and static sites are making a comeback. Thanks to developments in tooling and templating, static sites have the potential for greater complexity and flexibility, without the need for an unwieldy backend.
Charlotte and Jack at Lunar have recently been delving into the world of static site generators (hint: you're using one right now) and have put together a little introduction on how they work and why they might be a useful tool in the developer's toolkit.
A static site is a website made up of prebuilt HTML pages that use the same content and layout every time they load. As the name suggests, the HTML is fixed once served and cannot be altered or customised by the user.
The opposite of this is a dynamic website, where the HTML that is served to the user may change based on user interaction and other external triggers. The dynamic aspect of the site comes from the fact that pages are built during runtime, for example, when requested by the user.
There are a number of advantages and disadvantages to using one over the other.
Because static sites consist of prebuilt, unchanging HTML files, they load very quickly and efficiently, creating a more seamless user experience.
In contrast, a dynamic site requires communication with a server during runtime, which can slow down the user experience and impact upon performance scores. Modern users are impatient and keeping them waiting can have a huge effect on your site's usability, traffic and SEO.
A static website has no database filled with sensitive user data to hack into. This is always a bonus.
Static sites are simple and cheap to host, being merely a collection of files that can be uploaded to a web server.
In its simplest form, a static site could just consist of a single HTML and CSS file.
Of course, most modern websites require far more complexity than this with multiple pages, components and content that needs to be continually updated. Without some way to template the HTML files, maintaining a complex static site would be a tedious task indeed and one that would require the skills of the developer (popular content management systems, like Wordpress, that separate content from code, require the use of a database).
With the above in mind, a static site might seem limiting in terms of its flexibility and scalability. What's the point of building a site that your client cannot add content to easily? And what happens if, three years down the line, your client wants to change their branding across 300 pages of content?
This is where static site generators come in.
A static site generator (SSG) allows you to create a performant, secure static site using flexible, modular templates and separated content.
In real terms, let's say your client has a large number of blog posts they want to publish on their site and they want the ability to add more without coming to you to do it for them. If all your blog posts have the same layout and format but with different content, you don't really want to have to hard-code an HTML file. And your client certainly doesn't want to learn HTML to do that either.
With an SSG, you might have one template file for your blog post page and this template can be populated with different content depending on the post. This separation of content and code feels a bit like a content management system (CMS) like Wordpress, but without the performance and security issues that arise from needing a database and a backend.
No matter how complex the site, the SSG is still pre-rendering the HTML files so that they are all available on load.
SSGs are generally used as part of a JAMstack approach to delivering websites. JAMstack (which stands for Javascript, APIs and Markup) removes the need for the developer to use a database or a backend whilst still allowing for content to be separated and dynamically delivered. This is usually done via existing APIs (ie. someone else's backend problem) and Javascript.
There are a variety of different SSGs out there and plenty of information online about how they compare. But we thought we'd share a couple that we've been using recently at Lunar.
If you've ever done any research on SSGs you've probably come across Gatsby.
With Gatsby you use React and Webpack to create reusable, flexible components and GraphQL to query your content data, all of which is then compiled into static HTML and CSS files.
Gatsby is a good place to start if you are unsure about SSGs and want to test the waters with minimum effort. The Gatsby community is fast-growing and supportive and the documentation is extensive, easy to navigate and updated regularly.
Furthermore, the Gatsby Plugin Library is vast and allows quick and easy implementation of things like adding content platforms (such as Contentful) or headless CMSs, responsive images, hash navigation and so on.
If you're curious about what a Gatsby site looks like - you are looking at one right now!
NextJS is another of our favourites. Similar to Gatsby, it's a React based SSG that features a file system based routing setup, meaning that updating the structure of your website is as simple as moving some files and folders around, with the flexibility to include wildcards meaning you don't have to worry about having to define a file or folder for every possible version of a page.
NextJS is created by the team at Vercel, who offer a no-fuss approach to deploying your NextJS site, where redeployment is as simple as pushing some new work to your Github repository, and everything else takes care of itself.
NextJS also comes with a whole bundle of other features, like in-built Typescript support, CSS modules, SASS, automatic image optimization, file system based API routing and more. In addition to this, there is a wealth of examples of how to integrate NextJS with almost any technology you could imagine listed here.
If you are not a fan of React, then Eleventy allows for a variety of templating languages including JS, Nunjucks, and Handlebars among others. Nuxt uses Vue and Jekyll is a popular choice among Ruby devs.
At Lunar, we sometimes have projects that require the result to be a statically generated set of HTML files, but with the requirement that the project files be maintainable by people without familiarity with the above technologies, in which case we create our own SSG!
Writing out a whole bunch of HTML is a pain, so working within a system that allows us to easily call on component templates speeds things up a lot for us. We have built a dependency-free SSG that uses a tiny PHP setup script to run through some PHP templates and output their contents to a build folder that contains the final project files.
To save from having to run some PHP process every time we make an update, it also makes use of a little NodeJS script that listens for changes to files, and prompts the PHP script to rerun when it finds that something has changed. It also listens for changes to any SCSS files we have and compiles them to CSS, watches out for content updates, which we keep in some JSON files for a nice separation of the data we're working with and the view generating layer.
All of that means that we can work within a familiar template based system, where templates can be composed together, call on each other and generally have data from any source passed into them providing it has the right shape.
This system is not as fully-fledged as any of the famous SSGs, but for our use it suits the requirements perfectly: the output is easily separable from the code itself, and serving the site requires no programming language to perform any actions at runtime.
At the same time, the code is accessible and makes no assumptions about a future developer's proficiency with any particular system, asking only that they know PHP, SCSS and vanilla JS.
So far we've talked about Static Site Generators, but if you look at some of the technologies above, you'll probably come across another acronym: SSR, which stands for Server Side Rendering.
Gatsby and NextJS are both React based, and as you may be aware, React usually runs in the browser, that is to say on the user's device! These technologies run the React code for the first time on the server, and then deliver the HTML that is produced by that process to the user's device.
That means that the burden is taken off the user's device and can be tackled by the more powerful processing power of the server. It also means that in the cases where you do want to fetch some data from a database or an API, the server can do so and construct the HTML page with that data plugged into it.
Compare this to a traditional SPA (Single Page Application) where the flow of requests goes something like this:
In the case of SSR, we have a flow that's more along these lines:
The idea here is that the user's device no longer needs to run much code, and gets a pre-built HTML page ready to display to the user almost immediately.
However, that doesn't feel very different from just making a site with PHP or some other server side approach to building HTML from templates. The advantage with using a SSG here is that we get all the perks of a SPA: instant navigation through preloading the views for any pages linked from the current page, sitewide state management strategies that don't require sending data to the server or tracking sessions, all the logic you could need right at your fingertips without having to delve into separating your front end JS from your back end language, and a single React-based environment in which to develop.
There are still some areas where a traditional CMS, serving dynamic pages, like Wordpress has the edge over an SSG. Most notably, the Wordpress admin interface is very user-friendly and easily customisable by multiple non-specialist contributors (though it is possible to stick an SSG on top of a Wordpress CMS). Any site that is constantly updated with content by multiple authors might be better off using more familiar means.
For the Lunar site, we use Markdown for adding content, with the knowledge that our contributors all have some experience of working with Markdown syntax. But this certainly wouldn't be the case for every site we build.
But if your content management needs are less demanding and you are looking for a way to speed up the performance of your website, make it more secure, easier to deploy and host and yet maintain the reusability and flexibility of templates, why not try out a static site generator?
If this article was helpful, tweet it.
Drop us a line to discuss your project.
Call us on
Email us at