WordPress vs. Static Site Generators (SSGs)

WordPress, as most know, is a server-side processed content management system (CMS). For each page request, PHP code must be processed, executed, and database queries must be run. The final output of these processes is a standard HTML page.

The static site generator (SSG) community prides itself on performing these dynamic queries on the “build machine” (which is either the developer’s laptop, or a repository builder like Github, Netlify, or Forestry.io). Thus, when a visitor arrives at the built website, the HTML page is already built and ready to serve.

SSGs have shortcomings. They primarily struggle to deal with dynamic content. Dynamic content is anything that displays differently from one visitor to the next, or from one visit to the next. The very name “static” implies “unchanging”.

Since SSGs save the page “as is”, it can not be changed “on the fly”. There are workarounds for including dynamic content in static sites, but they aren’t nearly as easy to implement as a basic WordPress installation.

A common issue is allowing for comments. Typically, the workaround involves offloading the dynamic “feature” to a third-party site which does use server-side processing. Disqus is commonly used on SSGs that want to permit comments on articles. So, while it’s all well and good to say that static sites are “faster”, they end up doing workarounds like this and offloading various needed dynamic features to third-party sites.

This offloading presents a different set of problems. Now, another piece of third-party code (Javascript) must be included on the static site, and the website’s interactive data (comments, in this example) must be managed outside of the company. This is also true for CMS logins (if you want to, for instance, allow collaborative editing of a website), contact forms, or any kind of authorization or e-commerce cart management. (I’ll skip the payment authorization comparison since many CMSs offload that also due to the complexities and legalities of it).

Forestry.io’s says their service “transcends static”. Netlify’s heading asks its prospective customers to “go beyond static”.

Tell me this: what is the point of having a static site if you then need to go beyond static by using a third-party (or multiple third-parties) to regain the dynamic content features you gave up by going static?

I don’t want to debate SSG vs. Dynamic CMS here. Netlify and Forestry.io are the right solution for a subset of customers with unique needs.

However, it points to two very distinct trends we need to consider when we think about WordPress and its trajectory:

  1. These SSG services indicate an inherent weakness in WordPress that we should more closely examine. Developers looking to SSGs and these types of build sites with dynamic integration are finding, to some degree, fault with the current options in WordPress.
  2. There is also a clear trend for websites to focus increasingly on performance. We want our websites to be fast.

WordPress, as the largest CMS by far, has long-since proven its worth in 100 different ways. It’s easy, it’s universal, people intuitively can use it out of the box, from a first-time blogger, to advanced development teams building complex websites for corporate clients, including e-commerce sites and much more.

In other words, the future of SSGs is not certain, but WordPress, by any reasonable standard, is here to stay.

If we want WordPress to be performant, we have to keep an eye on the SSG community to see how they are handling and responding to consumer demand. To the degree that some relatively enterprise level websites are walking away from WordPress and other CMSs to rewire their site using an SSG and third-party services, we should see that as a trend we need to address.

(Just a small caveat: I see very strong use cases, historically, for some SSGs. The rise of Jekyll and its role as a solution to the 2012-13 Affordable Healthcare Act website debacle was an excellent use case. However, in my opinion, it should have been also an “all hands on deck” wake up call for Automattic and WordPress as to why the #1 CMS in the world wasn’t an option originally, and why (had it been chosen to be) could it not have easily handled the traffic without massive engineering workarounds.)