We’re looking at what static site generators are and how they’re different from dynamic content management systems like WordPress.
What is a static site generator?
A static site generator takes source files and generates an entirely static website.
There are many static site generators available used for all sorts of purposes. Some are for creating photo gallery websites from a folder of photos, others help you create documentation websites. The majority help you manage a typical website with a blog.
In this tutorial series we’re using Jekyll. Jekyll is actively maintained and has the largest community of all the static site generators.
To understand how static site generators are different, let’s have a look at how a dynamic CMS such as WordPress works.
How does a dynamic CMS work?
In this article we’re using WordPress as the dynamic CMS but we could easily swap this out for Drupal or the majority of other CMSs out there.
When a user goes to a page on a WordPress site, the request is sent to our web server (Nginx) then forwarded to WordPress. WordPress builds the page from a number of templates, gets the content and other site data from the database and sends the complete HTML page back to the user.
How does a static site generator work?
When we’re setting up our server, we take the static site created by static site generator and deploy it to our server. When a user requests a page on our static site, the request is sent to our web server (Nginx), which then finds the matching file and sends it back to the user.
Why use a static site generator?
Now we understand the fundamental differences between static site generators and dynamic CMSs, let’s have a look at why we’d actually use one.
When we’re setting up a static server, all we need is a web server that’s capable of serving static files.
To set up a WordPress server we need to setup our web server, PHP and MySQL. Then we’ll copy over our WordPress plugins, database and files from our development environment.
Serving a static site is extremely fast because all the web server needs to do is return a file. We can also make sure the site is perfectly optimized before we deploy it. We do this by running all the source code through minifiers, optimizing the images, using tools to remove unused CSS and other techniques.
On every request WordPress needs to build the whole page from scratch. This involves putting together all the template files and getting any content or other data from the database.
This is made worse if we’re using WordPress plugins. Each plugin will most likely need data from the database and time to process.
A lot of this processing can be eliminated by using a cache which means when a page is processed, it will save a copy for future requests. However this adds extra complexity and another point of failure.
We can perform some optimizations like minification to speed up the site but these are usually done on-the-fly.
There are only static files and a web server on our server, there’s nothing dynamic that can be exploited. It’s still possible to access the server if a hacker can find a vulnerability in the web server but the risk is greatly reduced.
Hackers often look for out of date WordPress sites where there are known exploits. So the main way to keep WordPress secure is making sure it’s kept up to date. The database is also a potential point of access if it’s misconfigured. There are security plugins available which help prevent common misconfigurations.
Every WordPress plugin we install is a potential access point for a hacker. Access was gained in the Panama Papers incident by exploiting an out of date slider plugin.
A single server can handle a lot of traffic if it’s just serving static files. However, if we need more resources (or redundancy) we can load balance traffic across multiple servers. This is relatively easy to set up as we just need to make sure the static site is on all our servers.
To scale WordPress we can deploy our WordPress environment to multiple servers and have our database instance on a single separate server. At some point we’ll need to have multiple database servers as well which adds another layer of complexity.
All the source code for our Jekyll site can live in a version control system like Git. With Git we can go back to any single version of the site in its entire history. This also serves as an offsite backup, if we ever need to restore a server all the files we need are in the Git repository.
We can create branches which allow us to work on multiple versions of the site and merge them together later. This is extremely useful when we have a large team of developers as they can work simultaneously. It also means they can clone the production environment on their local machine with minimal effort.
If we take this a step further we can even have our source code in an open source repository on GitHub and have anyone make updates and suggest merging it into our live site.
In WordPress we have the ability to revert changes on an individual blog post. We need to ensure we’re backing up the database regularly and keeping track of the themes, plugins and assets we’ve uploaded.
If you’re interesting in trying out Jekyll you’re in the right place! This site takes you through everything you need to know from installing Jekyll, to advanced use cases.