Why I Chose a Static Site Over a CMS

When Using a CMS is So Easy, Why Bother?


11ty, my static site generator of choice

Yesterday I published an article about the setup I'm using to manage this site. As you can see from that write up, putting this whole thing together based on Eleventy took quite a bit more time than it would have to just install WordPress / Ghost / Grav / Craft somewhere and immediately hook into writing.

In fact, I did start by installing WordPress and published a single short post there. However as much as WordPress has been an amazing part of my life, and as much as I love other systems like Ghost and Grav and Craft, I'd been hearing chatter about how much people loved their static sites and it appealed to me for several reasons.

Here's why, to me, using a static site generator is so much of a powerful draw.

Loading Speed = Enjoyable Visits & SEO

Load speed under a second

Note the image above is a live load speed test done on yesterday's article. DOMContentLoaded in under a second, complete load in only 1.44s.

A static site like this has no database requests to make, no templates to render, basically no processing to do other than just drawing the page. Why? Because I handle all that processing myself in my own time before uploading changes to the site.

This effectively means I save that time from being spent by visitors to my site. You don't have to wait for a thing, because every part of the site is completely ready to be served. As fast as your internet connection can move, is as fast as you can access my site.

I noticed how blazingly fast and snappy SSGs were as I browsed demos of the various builders, with pages loading near instantly.

As someone with a couple of decades spent applied to the task of maximising load speeds, of course my thought on seeing these efficiencies was "I have to have this".

It's also critical these days for SEO that your site be as fast loading as possible. The laggier your site load speeds are, the less the search engines want to know you.

Fast load speeds are critical, and I've seen nothing yet that's faster loading than a static site.

Minimal Server Requirements = Flexible Hosting

Despite my using a SSG here, I really like a bunch of different CMSs, including WordPress, Ghost, Grav, Craft and a few others. And there are certain types of sites that absolutely require dynamic systems like these.

However it can be a PITA organising hosting that caters to all the types of site dev you want to do. If you want a server that can host your LAMP stack sites, your NodeJS based sites and your JAMstack sites, you're probably going to need a VPS. Having a VPS is great and all, I have one myself, but I don't always want to handle all the server admin when there are companies with great services who can handle so much of it better than I can. After all, I'm a front end web dev not a sysadmin, so it's not my wheelhouse.

By using an SSG I simplify my hosting requirements down to their absolute baseline. I can host this site on absolutely any host. So if I want a host that works for LAMP stacks, JAMstacks, NodeJS oriented stuff, or whatever else, I can host this site on that same service.

Minimal Server Resource Usage = Low $$ Expense

Memory use on Cloudways

On top of being able to host this site on any type of host, because there is no back end processing the system resources used are absolutely minimised.

I'm currently hosting on Cloudways and this service gives me the ability to scale the rate I pay according to the system resources I need. I have a certain amount of CPU and RAM allocated to my account, and I can do with those resources what I wish. I will only need to pay more if I find my sites cannot be efficiently served with the resources I have. By hosting only static files, I can have more sites and more visitors served at high speeds in the most cost effective way.

Choice and Control = Happy Coding

As anyone who has been doing any type of dev will attest, we all find over time that we develop our own ways we like to do things. We like or organise our code and our project in a certain way. We have patterns and paradigms we like, and those we don't.

This very much carries over into how much we like doing dev on whatever site or project we happen to be working on. There are some CMSs that are an absolute delight to dev themes & extensions for, and there are some that are frustrating and restrictive. Beyond that, we each prefer different templating languages, CSS preprocessors, approaches to JS and so on.

With this system I have freedom of choice to organise and construct things however I want, using whatever tools I want. And I have total control over what happens in my setup. With someone else's CMS I have to go along with what the developers decide to do, (which is of course their prerogative), and sometimes I will love changes but sometimes I won't.

Here, in my little custom blog land, I love all the changes.

Security = Low Maintenance

I used to run a WordPress site that had a member's area, as such it needed to have a public facing login page. That page was under bot brute force attack 24 hours a day, 7 days a week. Securing it was certainly doable, but it was time that could have been better spent on something more constructive. Even on dynamic sites that don't require a public facing login page, security is a constantly present issue that always needs to be attended to and drains time and resources.

With a static site, it's inherently secure. There is no admin area to exploit into. There is no database to pwn. There is no login page to brute force.

This, to me, is a huge relief and a problem I'm very happy not to have to deal with.

Ease of Change and Customisation

With this site I have my content and site files side by side, in the directories content and resources respectively. I could organise things this way because Eleventy gives me complete freedom of choice in how I set things up.

This means that when I want to change something it takes seconds. I don't need to refer to a knowledge base to find out what system idiosyncrasies I need to work with, I just make the changes I need immediately, right here in the folder I'm already working in, using VSCode the software I'm already writing in.

And because of this freedom of structure I've also been able to have my VSCode config files in the same place as well, meaning I can update them on a whim as well, evolving my processes as I go.

For example, after inserting the image at the start of this article I just decided I wanted to make it easier to insert a right or left aligned image. So in about 30 seconds I added two new snippet to my system: imgr, which expands to ![]() {class=imgright}, and imgl which expands to ![]() {class=imgleft}. This adds classes to my images I already have CSS styles for, handling my image alignment.

Bliss.

Ease of Backup

Git for Backups

Because I have no database to worry about, and all my files are on my local machine, backing up this site is as easy as it can possibly be. If I wanted, I could just zip everything up and put it on a storage device.

But to make it even easier than that I have git repositories for both my source files and built site files. I add content, then simply push both repos. Done.

100% Worth It

I love this system so far and all the benefits I described above. I will certainly still use dynamic sites when the need arises, but I will use static sites everywhere I possibly can.

If you're interested in doing something similar, Eleventy is my SSG of choice for its agnostic approach to code and its simplicity & speed.

And for hosting I recommend Cloudways for its low cost, high speed, git deployment, integrated CDN and resource based pricing model.

Wanna chat about this post? @ me on Twitter

Tags: | blogging | site systems

<- Home