7 Reasons to Use a Static Site Generator

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

Static Site Generators

Static site generators have become increasingly popular and, if my prediction is correct, usage will explode during 2016. Let’s establish what we mean by the term “static site generator”

static site generators

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 — which allow authors to write content that’s stored in a back-end database. When a visitor requests a URL, the CMS:

  1. determines which page is required
  2. requests appropriate content from the database
  3. loads an HTML template (normally from the file system)
  4. renders the content within the template, and
  5. 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 one in four 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-only website using CMS-like concepts such as templates. The content can be extracted from a database but, more typically, Markdown files are used.

The site generation can occur on your development machine or staging server. The resulting HTML files are then deployed to a live web server. 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. Therefore, an SSG could 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 accessible from outside the organization.

Popular static site generators include Jekyll, Pelican, Hugo and Metalsmith — see StaticGen for many more. Let’s examine the benefits of using one …

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 cache 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 are pre-cached pages which never expire. Files can also be minified prior to deployment to guarantee the smallest load. 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 any part to cause chaos.

A static site is lightweight, and can be hosted by any web server able to return HTML files. There is nothing else to install, manage or update.

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 crash the database or restrict active connections.

Serving a static site is less intensive — the server just has to return flat files. It’s still possible to crash a web server, 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 — for example, 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 has little or no server-side functionality. You cannot access it via scripting or database security holes. Someone could still gain access via SSH or FTP, but they would struggle to do much damage other than defacing pages or uploading files. A quick git status or folder check can reveal break-ins. It’s then simple to change passwords, wipe the whole site and regenerate it again.

6. Client Control Considerations

You spend weeks building attractive CMS themes for the client to trash their site within minutes of your hand-over. 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, adding weird colors, using poor photography or corrupting the layout.

A static site can use Markdown files. That limits the user’s options; they make fewer mistakes and cannot adversely affect the pages. Some will miss the CMS content administration panels, but you can either:

  1. use their existing CMS and cleanse data before generation, or
  2. provide simpler workflows such as editing Dropbox files in StackEdit.

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 safe presuming your content is defined in Markdown files and you use a version control system such as Git. Old files are retained, and changes can be undone quickly. Testing 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 on a staging server, then update the live server when new content has been 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. And for a practical demonstration of how to build a site with a static site generator, see my How to Create a Static Site with Metalsmith article.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Great!

  • JanySmool

    Hi, it is awesome stuff!

    It is very cool that you can explain
    such things with easy words, and I understand it! I think all readers
    agree with me) Also, Can it help in SEO or in marketing? I am a beginner in this topic and I would like to know!) Thank you

    • Craig Buckler

      A static site won’t directly aid SEO except that performance should be better and the build process may help developers spot content editor mistakes, faults, gaffes, blunders, oversights, lapses.

      • JanySmool

        Ok, thank you for your answer!

  • Sp4cecat

    Hi Craig, I’ve always been a fan of reducing framework bloat, but a good caching mechanism is essentially an on-the-fly generated static site .. you get more overhead in cache management and generation, but better flexibility and you can use existing skill sets, plugins and code.

    Coupled with server-side micro-caching, you get performance akin to a static site (with a bit more CPU load, sure)


    • Craig Buckler

      Good caching gets close to static-site performance but there’s still some overhead and a CMS can fail if the database goes down – regardless of what’s been cached.

      Another option is static-site generation from the CMS. In other words, it’s a one-off generation process so the HTML files can be transferred to another host while the CMS remains securely isolated on another server (as Rob suggests below).

      • Sp4cecat

        Agreed. But given the topic, it’s such an obvious, “Hey, but what about ..” that I figured it worthy of comment

    • I agree with Craig. I tell people you won’t have a database error if you don’t have a database.

      The other big difference is security. Nothing is 100% secure, but you have fewer entry points if you don’t have an actual application running on top of the web server.

      Of course the choice of which set of tradeoffs is best for you is up to you. Neither static site generators or a dynamic CMS is intrinsically the best choice. Which is better a saw or a hammer? Depends on what you’re doing, right? ;-)

  • @craigbuckler:disqus If you think your readers would be interested in my course, I have some promotional subscription cards. I could give you five to give away as a contest or something. I can also get you one if you would like to watch and/or review the course. I followed you on twitter, so just DM me there if you would be interested. I’m jeffa00 on Twitter.

  • Sp4cecat

    A gorgeous solution – pair it with cheap caching (CloudFlare) and you’ve got a robust, maximum uptime CDN hosting solution

    • Rob Moorman

      Absolutely. Actually there is already CloudFlare cache invalidation support when you publish pages from Wagtail. In the upcoming 1.5 there also will be support for CloudFront.

  • I’m using Hugo for my blog and hosting it on gae as static files + cloudflare.
    Also it’s really nice and I love it, but it still requires some clicks. (and I even don’t mention image upload and resize).
    I mean imo for personal blog using blogger is the way to go.

    And for clients in most cases you will need to have admin panel. That’s why static site generators have a very limited usage cases.

    If some static website generator would have some ui with uploading + resizing images and button upload to ftp, I guess they will increase popularity.

  • Tunji Oloruko-oba

    The world has sinply outgrown static websites. Even the smallest businesses or clients want to be able to add new stuff, add new images to slider, upload photo album etc features that are simply out of a static website’s league.

    • Craig Buckler

      Why do you consider that to be the case? A static site means the files are static from the point they’re generated … much like a WordPress cache but more permanent. Anything you can do in a CMS can be done by an SSG.