Setting up this blog - why I opted for static content over a CMS
When I decided to start this blog, one of the first decisions I had to make was, what stack should I use to build it? There are basically three different approaches:
- Build the site from scratch
- Use a CMS (there are many solutions out there, including Drupal, Wix and WordPress)
- Use a static site generator such as Jekyll
As a web developer, building the site from scratch would have been no problem, but was it really necessary for something as simple as a blog? Almost certainly not, and as I was keen to get going as quickly as possible, I discarded that solution.
This reduced the choice to one between a CMS and a static site generator. To make my decision, I considered the following criteria:
- Functional support (does it do what I need?)
- Ease and cost of set-up and hosting (how quickly and cheaply can I get going?)
- Framework complexity (how much is going on behind the scenes when the site runs?)
- Performance (how quickly do the pages load?)
When evaluating these criteria, it was important to consider my use-case - a simple, static blog that supports a moderated comments section, possibly Google analytics, and not much else. It’s always important to bear in mind what you’re actually trying to do - YAGNI applies here. If I needed to build something more complex, with a shopping cart, badge system and authorisation, for instance, the results would have been different. However, the criteria and general evaluation approach would have remained the same.
Evaluation
For the evaluation, I decided to compare two representative technologies: WordPress (CMS) and Jekyll (static site generator).
Functionality
Both approaches were more than adequate. WordPress was frankly overkill for my use-case, and Jekyll comfortably met my needs.
Verdict: draw
Setup and hosting
There are free hosted solutions for both WordPress and Jekyll. A number of companies offer free WordPress hosting. Most of them have bandwidth limits of 5-30GB, although WordPress.com offer unlimited bandwidth. The setups are of varying levels of complexity, with WordPress.com offering one of the simplest, albeit with a some bloat that needed to be removed.
GitHub Pages is a popular solution for hosting Jekyll, offering 100GB bandwidth. It’s exceptionally easy to set up - I simply forked this example repo, updated the markdown file for the first post, and was on my way, all on my phone. The downside for non-technical people is that you need to be familiar with markdown and GitHub, but for me this was a positive, rather than a negative.
Verdict: draw (depends on your preference for WYSIWYG vs. markdown)
Framework complexity
This one was easy: WordPress is a full-blown CMS backed by a database and a framework to dynamically turn database content into html pages, whereas Jekyll compiles a set of static html and css files. For each request, a WordPress site is simply doing a lot more processing than an equivalent Jekyll-generated site.
Verdict: Jekyll
Performance
Since WordPress does a lot more processing per request than a Jekyll-generated site, you’d expect it to be slower. However, in IT, you should never make assumptions without measurement - there could be all sorts of reasons why WordPress sites worked out quicker in practice, such as use of CDNs and caching, better hosting, etc.
WebNiyom does an interesting comparison of two self-hosted sites, where Jekyll came out the clear winner (it was around 50% quicker). However, to do a fair comparison, I decided to use PageSpeed insights to compare sites hosted using two common simple solutions: WordPress.com and GitHub Pages.
I recreated the blog on wordpress.com. PageSpeed insights gave it a score of 82 for mobile and 94 for desktop. The Jekyll site had a perfect score of 100 for both. (Note that each run will give slightly different scores, and this blog will have changed considerably since I did the test.)
Verdict: Jekyll
Conclusion
An objective evaluation of both approaches led me to the conclusion that Jekyll/GitHub Pages was the best solution for my use-case. For owners of simple, static blogs, I’d strongly recommend eschewing heavy CMS platforms in favour of much more lightweight static site generators. However, the most important thing for me is to evaluate technologies objectively based on my specific use-case, to measure what can be measured (e.g. performance), and to come to a conclusion based on the evidence, not on preconceptions.
In my next post, I’ll be talking about tanagra.js, my open-source, lightweight Javascript serialiser.
