7 Reasons to Use a Static Site Generator
Static site generators (SSGs) have become increasingly popular over the past decade. This article discusses how your site could benefit from the developer-friendly build processes, easier deployments, improved performance, and better security offered by a static site.
First, let’s establish what we mean by the term “static site generator” …
What is a Static Site?
Think back to the first website you built. Most developers start by creating a series of pages contained within individual HTML files. Each will call in assets such as images, CSS, and perhaps a sprinkling of JavaScript. You possibly launched these files directly from the file system without a web server. Life was simple.
Difficulties arise as your site becomes larger and more complex. Consider navigation: it may be similar in every file, but adding a new page requires updates to every other. Even references to CSS and images can become awkward as folder structures evolve. You may have considered options such as server-side includes or PHP, but an easier option can be a content management system (CMS) …
What is a Content Management System?
A CMS typically provides administrative control panels. These allow authors to write content that’s stored in a back-end database. When a visitor requests a URL, the CMS:
- determines which page is required
- requests appropriate content from the database
- loads an HTML template (normally from the file system)
- renders the content within the template, and
- returns a formatted HTML page to the visitor’s browser.
This occurs almost instantly. The template can include code to generate menus according to the navigation hierarchy. Life is sweet, and more than four in ten people choose the PHP/MySQL-powered, open-source WordPress CMS to manage their website.
Unfortunately, a CMS raises a different set of issues:
- You need to adhere to the CMS’s way of working. It can be awkward to add custom text or components.
- The server is doing more work, and performance can be affected.
- There are additional points of failure. A software upgrade or database failure can bring your site down.
What is a Static Site Generator?
An SSG is a compromise between using a hand-coded static site and a full CMS, while retaining the benefits of both. In essence, you generate a static HTML page-based website using CMS-like concepts such as templates. The content can be extracted from a database, Markdown files, an API, or any practical storage location.
The site generation can occur on your development machine, staging server, or using a service to build when changes are pushed to the code repository. The resulting HTML files and other assets are then deployed to a live web server.
The term “static” doesn’t mean “unchanging”. An SSG builds a page once, while a CMS builds it on each request. The end result is identical and users will never know the difference.
A related concept is a “Headless” or “Decoupled” CMS. These use an interface such as WordPress to handle content administration but allow other systems to access the data via a REST API, or a GraphQL API. Therefore, an SSG such as Eleventy can build a static website using WordPress page content extracted from an internal server. The resulting HTML files can be uploaded to a web server, but the WordPress installation need never be publicly accessible from outside the organization.
The term Jamstack (JavaScript, APIs, and Markup) is also used in relation to static sites. It refers to the rise in frameworks, serverless functions, and associated tools which generate static files but allow more complex interactivity to be created.
Popular static site generators include Jekyll, Eleventy, Gatsby, Hugo, and Metalsmith. SSGs are available for most languages (see StaticGen for many more). Frameworks such as Next.js statically render pages where possible, but also allow the developer to run server-side code when necessary.
Let’s examine the benefits of using an SSG …
1. Flexibility
CMSs normally constrain your options, because they’re tied to a database with specific fields. If you want to add a Twitter widget to some pages, you’ll normally require a plugin, a shortcode, or some custom functionality.
In a static site, the widget can simply be inserted into a file directly or using a partial/snippet. There are few limits, because you’re unshackled by the those imposed by a CMS.
2. Better Performance
Most CMS applications offer built-in or plugin-powered caching systems to ensure pages are generated and reused when possible. This is effective, although the overhead of managing, validating, and re-generating cached pages remains.
Static sites can create pre-cached pages which need never expire. Files can also be minified prior to deployment to guarantee the smallest load and easily deployed via global content delivery networks (CDNs). A static site will always perform better than a CMS-powered version using a similar template.
3. Fewer Server-side Dependencies
A typical WordPress installation requires:
- a suitable operating system such as Ubuntu or CentOS
- a web server such as Apache or NGINX
- PHP with associated extensions and web server configurations
- MySQL
- the WordPress application
- any necessary plugins
- the theme/template code.
These dependencies must be installed and managed. WordPress requires less effort than some other applications, but it’s still possible for a single update to cause chaos.
A static site generator may require just as many dependencies, but they can run on a developer’s PC and are not deployed to a production server. An SSG generates client-side HTML files and associated assets which can be hosted on any web server. There’s nothing else to install, manage, or maintain.
4. Improved Reliability
A CMS is complex, with many moving parts and points of failure. Run a WordPress site for any length of time and you’ll almost certainly encounter the dreaded “Failed to establish a database connection” error. Unforeseen CMS problems can arise from sudden traffic surges, which overload the server, crash the database, or restrict active connections.
Serving a static site is less intensive. In many cases, the server just has to return flat files so scaling according to traffic demand becomes simple. It’s still possible to crash a web server or overload APIs, but it’ll take considerably more concurrent requests.
5. Superior Security
There are several reasons why someone may want to attack your website. Traffic hijacking, rogue advertising, linking, authenticity spoofing, and malware hosting all permit an unauthorized user to make monetary and/or kudos gains.
A CMS opens a number of attack vectors. The most obvious is the login screen: it’s only as secure as the weakest user password. Be aware that any page running server-side code also offers potential exploits — such as firing spam emails via your contact form. It may not be obvious that someone has gained access; the worst culprits want to stay hidden.
A static site may require little or no server-side functionality. Some risks remain, but they’re rarely as problematic:
- Someone could gain access to a server via SSH or FTP and deface pages or upload files. However, it’s usually simple to check for changes (perhaps using
git status), wipe the whole site, and regenerate it again. - APIs called by a static site are exposed in the browser and could be exploited in an identical way to any server-side code — such as a form emailer. Good security practices, CORS, and CSP will help.
6. Client Control Considerations
You can spend weeks building an attractive CMS theme for the client to trash their site within minutes of handover! Using a CMS is not necessarily easy, and it offers considerable power to content editors. You can lock down rights such as plugin installation, but it won’t prevent someone changing fonts, introducing clashing colors, adding poor photography, or corrupting the layout.
A static site can be as limited or as flexible as you choose. If you’re using Markdown or similar flat files, editors are less able to make mistakes or adversely affect page styling. Some will miss the CMS content administration panels, but you can either:
- use their existing CMS and cleanse data before generation, or
- provide simpler workflows such as editing Git-based files in StackEdit or Hackmd.io.
7. Version Control and Testing
Database data is volatile. A CMS permits users to add, delete, or change content on a whim. Wiping the whole site is a few clicks away. You can back up databases but, even if that’s done regularly, you’re still likely to lose some data.
A static site is generally safer. Content can be stored in:
- flat files: they can then be version controlled using Git or similar systems. Old content is retained, and changes can be undone quickly.
- private databases: data is only required when the site is generated so it need not be exposed on a public server.
Testing also becomes easier because the site can be generated and previewed anywhere — even on a client’s PC.
With a little more effort, you can implement deployment systems to build the site remotely and update the live server when new content has been pushed to a repository, reviewed, and approved.
So all is good in the static site world. Or is it? Read my follow-up post on 7 Reasons NOT to Use a Static Site Generator.
For a practical demonstrations of building sites with a Static Site Generator, see:
