One of the biggest questions I get from clients, and even agencies, is what is static development? What is headless content management? And why should we be moving to it instead of WordPress?

Sometimes they've heard about it but they're either not sure about it, the benefits, or they're afraid to make the leap to something that they haven't seen proven.

But I guess before we touch upon that, a better question to ask would be, why do we still use WordPress?

WordPress is just one example of hundreds of content management systems available, but still accounts for 30% of the web, and still the go-to choice for many agencies and client alike. Not because it's popular by how it functions, but because they're afraid to give the other options a crack.

This isn't to slate WordPress completely. It's a great content management system, but we're using it wrong. We're using blindly without consideration of what it was originally designed for, which was blogging. A title and body, nothing more, nothing less. Now we're building out massive e-commerce sites and publishing houses based on an architecture that hasn't changed much since its first conception.

The one thing that all these types of content management systems have in common is that they tend to run as an all-in-one, or "coupled" system. You might have the database management separately as an independent microservice, but the actual separation of website and CMS is still a coupled product. Basically, the website requires the backend to display anything.

With static development, we simply remove the moving parts. We generate all the HTML upfront when we publish. That's instead of having the server getting the request, initialising a heap of code, pulling from the database, deciding how to show that content, then generating the HTML, and eventually sending to the visitor. Possibly sending, and usually not very fast.

With static, it means we have the entire website ready to go and always on.

Sounds great huh? But why is moving away from this monolithic approach to a static headless approach better still?

Faster

Instead of your website having to fetch and process website data and associated components from the CMS and the database, your website is already prerendered and ready to go. It's always available, as it was from the initial build.

Most modern WordPress installations monolith or decoupled content management systems usually have a cache system for static output, but even with that, the speed differences can be dramatic. And even with that, you usually have to pay through the roof the privilege of using an overpriced caching system.

Secure

The gateway to your content and brand should never be publically accessible off the same domain as your main site. Whoever thought that was an amazing idea?!

There are a number of ways you can hide this with WordPress and other platforms, but with a static approach, you don't even have to worry about it. Usually, with a separate build approach, you'll be dealing with a build provider and CMS service that takes care of the security for you.

Not to mention that most websites that use WordPress or something similar, also blindly using plugins without much consideration on how it impacts the end customer. Adding overhead to the performance of the website and a security risk. Here's a list of 21626 WordPress core vulnerabilities.

Reliable

Depending on how you serve the static HTML, you don't have to worry about the server becoming unavailable or a sudden influx of traffic bring down your e-commerce site. The number of times I've seen websites go down either due to a server error, migration downtime or a peak in traffic due to a marketing campaign, and it's beyond me why this should ever happen.

With a static headless approach, you shouldn't have to worry about this happening. It does depend on how you end up serving your static HTML, but with a standard serverless approach, the website will always be available, even with high traffic.

And that leads me on to...

Cheaper

Depending on how many people use your website, the price difference can dramatic. As the number of visitors increases the price difference is considerable, especially if you're running your monolith website on a scalable stack that increases your costs blindly. And you've forgotten to set your billing alerts 🙄

With a static solution, you don't need to do this and you only pay for data usage through traffic, not server uptime usage.

I pay literally nothing on a free tier hosting provider for most clients.

Scalable

From the front-end technology you use to where your content is consumed, having your content and data on a headless solution allows you to scale beyond your website, meaning your content becomes agnostic from its original home. It could mean that beyond your website, you can provide content to a mobile application or even IoT.

Content migrations when upgrading your website are no longer necessary either. The content state is completely decoupled from your website, so whenever you upgrade your design, you shouldn't need to worry about the themes or data structure as much as you would with a traditional coupled website. This saves an incredible amount of time and cost when switching to new website designs and branding.

Arguments against

But even with all these amazing benefits. Cheaper. Quicker. Faster. It's easy to see drawbacks too, especially if you're not used to this approach.

Here are just a few of the questions you'll get if you ever decide to offer static development as a developer or an agency.

But we want our website to publish instantly

Define instantly? 2 seconds, 5 minutes, and hour?

Depending on how large your website is and the amount of data you have, the build time can vary between a few seconds and a few minutes, but I haven't come across anything yet within the realms of smaller or agency based websites where the time has gone beyond 3 minutes.

Even with the largest website I regularly manage, the average build time, with synchronisation to the storage, it's roughly 2 minutes. And they're massive content managed websites with hundreds of pages and e-commerce products.

I have encountered issues with the build failing in the past, but that's mainly due to the content management system going down or the website data structure not been managed correctly on the front-end. These can be fixed easily, and luckily it doesn't impact your website visitors, because everything that goes wrong is hidden away in the build.

We can't do personalisation and signed-in state with headless.

There are a number of ways you can do this depending on what type of personalisation you want to do. Most of the more complex CMS solutions provide some element of this and available integrations, but you can also build out your own. From Firebase functions to building out your own serverless API.

The great thing about this too, is that you're building functionality away from your website, which should be your aim anyway. Websites have a future for sure, but also a limited one. Think about future-proofing your data now, so you can start to integrate your services into other mediums such as voice and video, like IoT.

Open

As part of this, I've made www.thingsthat.com completely open source for everyone. Yup, the code is open and free. Build what you want from it. It's super simple, so all the content is managed in code at the moment. You can find it at https://github.com/thingsthat/thingsthat-website

This was just a quick article on static development, which is just one part of the equation. Next time, I'll go in-depth the various headless content management providers out there, and how to implement them into your static solution. Including how I'm going to integrate a headless CMS into www.thingsthat.com.