To SSG or not to SSG


Category:  programming

Tags:  grav rss ssg website

...that is the question:

Whether 'tis nobler for the website to suffer

The databases and complexity of CMSs

Or to take arms against the sea of bloatedness

And by opposing end them? To switch: to rewrite;

No more; and by switching to say we end

The endless debate and the thousand woes

...you get the point.


In order to eke out ever-more performance from my piddly server, I've been trying to see what services I can cut down on. I moved some containers to bare-metal, I disabled some unused websites on Apache, so on so forth. Something I was considering switching away from current content management system (CMS) Grav toward a static site generator (SSG) like Hugo.

For reference, an SSG is a static site generator, where input files are converted into plain HTML, CSS, and Javascript which can be served by a regular web server. A CMS dynamically generates this content on-the-fly. Popular CMSs include Wordpress, Joomla and Drupal. Popular SSGs include Jekyll, Hugo, and Eleventy

I chose not to.

Why?

Ignoring that I don't have the energy to hop programs again and would rather settle for something stable and something I know works well for me, I'd prefer to keep a CMS over an SSG.

Search

I hate frontend search. It's slow, unreliable, and heavy for the client. Backend search is just so much better. I don't wanna have search run through Algolia or Google or whatever. I also do not want to give the client an entire index to look through. It's too much, especially once the website becomes larger and larger. At the moment, I have roughly 95,000 words written on the blog. Indexing and accurately searching this information with typo tolerance is slow, and especially bad for low-end devices.

Dynamic Content

I don't care much for comments, but many people would like them. Loading comments through third-parties is an option, but slows down page loads for the client and also likely introduces privacy concerns.

Alongside comments, filtering content (especially with RSS) can't be done without Javascript (or in the case of RSS, can't be done at all without server-side scripting). I just want to see all of the posts that have a certain tag in my feed. If I ever start writing fiction, filtering it out in RSS would be trivial… as long as the RSS feed isn't a static file. RSS is the backbone of blogging, so please have good support for it.

A CMS can be fast and light too

If configured right, a CMS is (almost as) fast as and (almost as) light as an SSG. Throw in a cache and load times are the same as loading an HTML page from an SSG (maybe a few milliseconds slower).

Command to test latencies used:

for i in {0..10}; do                                                                                     22:00:26
curl 'https://example.com/test.html' -H 'Accept-Encoding: gzip, deflate, sdch' -H 'Accept-Language: en-US,en;q=0.8,ja;q=0.6' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36' -H 'Connection: keep-alive' --compressed -s -o /dev/null -w  "%{time_starttransfer}\n"
done

The results (done once targeted at my Grav CMS and done once targeted at a static HTML file with the same response as the Grav CMS) are as follows:

0.044268
0.060754
0.058302
0.058605
0.057341
0.057831
0.056941
0.055844
0.058304
0.056649
0.038276

Avg: 0.054828636
St.Dev: 0.006950993

Keep in mind that I'm on the same network as the server.

Performing the same tests for loading the same page from the same server but as a static HTML… loads faster.

0.028479
0.025570
0.042270
0.045071
0.041505
0.033797
0.041684
0.034626
0.029464
0.027931
0.029943

Avg: 0.034576364
St.Dev: 0.006917524

Huh.

I'll just go ahead and rationalize this:

  • A difference in 10-20 milliseconds is imperceptible to the user for the initial page load.
  • The benefits of a CMS outweigh the slight reduction in pure page load times

As for databases and whatnot, you don't need to use Wordpress. For 99.999% (estimated) of the people who are running Wordpress, they don't need to use Wordpress. They don't need a database, or whatever else. They just want something that's easy to manage, which brings me to my final point:

A CMS is SO much easier to use

The flow of using an SSG is not instantly accessible to the average content creator, or programmer for that matter. A common setup I see is hosting the SSG's information in a Git repo, then using GitHub pages or another CI/CD action to build and deploy the page. This is simple enough, but the moment you try to do anything mildly complex, such as managing drafts without publishing them, using that workflow becomes cumbersome to the beginner programmer. Of course you can have two branches: one for the drafts, and one to deploy, or deploy based on tags, or something like that. Again, it's cumbersome and requires much more of a degree of technical competency and a willingness to battle Git. Compare this to the admin panel in modern CMSs, it's a no-brainer to use a CMS for the UX.

Full disclosure: I'm using Git to manage my website anyway instead of the Grav admin panel.

So what does it all mean?

A lightweight CMS is probably better to use than an SSG. It really depends on who you are too. If you don't care much for search or filters or whatever, and feel comfortable with Git, go for using an SSG. Deploying an SSG to GitHub pages or Cloudflare is reliable and free. Managed CMSs are typically not free and aren't as reliable as hosting a static page for free from those providers.

For most of you who are planning to start a blog, I'd recommend to stay away from an SSG and urge you to use a CMS. Focus on writing the content, not battling the website. Of course, if you have the technical acumen to self-host an SSG, go for it!

As with everything else, there's a use case for both. It boils down to this:

  1. If you want to focus more on content and less on managing your website, use a CMS.
  2. If you want dynamic features (comments, tags, etc), use a CMS.
  3. If you want something free and reliable (without self-hosting), use an SSG.

If you are planning to self-host, it can honestly swing either way. If you're running everything from an über-low-power machine, an SSG is likely the best bet. Otherwise, the dynamic content from a CMS is just too good to pass up. A CMS is so much more versatile and easy to manage and use. But, I guess it boils down to a difference in opinion and use case.

Let me know what you think.

Previous Post Next Post