Switch to a headless CMS and you'll never look back

In this article, we'll look at the following...

Is your CMS selection process serving you well?

When selecting your current CMS, did you set criteria? Or were you led by your sales team, IT team or perhaps even your digital agency?

The Content Management System (CMS) you choose to build your website around is a crucial decision and it is usually one of the first considerations for a content or marketing team.

However all too often, the decision-making will neglect to factor in the ability of the final solution to achieve strong Core Web Vitals. These are as fundamental to your SEO performance as they are for the end user experience. Two references almost guaranteed to be included in any website brief.

Opinions will frequently surface a bias towards a particular monolithic CMS due to familiarity. This will often be validated by sharing myths (usually inaccurate or outdated) about the failings of the other close contenders.

More often than not, the limited selection criteria will focus on solving a specific bugbear of the existing CMS and will rarely consider the needs of the business, key objectives for your website or even the capabilities now available from the many alternative CMS applications.

These scenarios go hand-in-hand with those who describe the significant delays in their website project, the inflexible configurations and endless limitations placed on the content authors, administrators and developers; quickly leading to a stale and under-performing website.

Does any of this sound familiar? It doesn't have to be this way.

Rather than battling against a monolithic CMS architecture, read on to hear how the maturing headless CMS options provide faster website design and build, lightning fast website performance and flexible content authoring to help the brand tell their story in an almost infinite number of ways.

What is a monolithic CMS and how does it differ from a headless CMS?

What you may hear described as a "traditional" CMS application (usually open source) provides an all-in-one solution. This is your monolithic CMS.

The application dictating the content authoring and administration experience, also manages the storage and access to data, configuration and content. It will also include the code for the front end presentation in the browser.

WordPress, Joomla, Kentico and even Drupal (but only during brief moments of weakness!) are examples of monolithic CMS applications you may be familiar with.

Removing many of the micro interactions which can create bottlenecks, this is what a top level view of the monolithic CMS set up usually looks like:

Conversely, the headless CMS solutions detach the code for front end presentation and the delivery of the web page to the browser away from the administration and content / data storage. Taking just this step can drastically improve the flexibility afforded to your website, not to mention the increased security inherent in this set up.

To really hit top marks on website performance, you can use the APIs from your headless CMS within clever build processes. This can be used to request each page of your website, automatically create (that's the build) and store them as static files on a scalable storage solution (e.g. AWS Amplify / S3). This means you get lightning fast performance for your end users since the overhead to deliver the page has already be spent, for everyone, before anybody even requested the page. This is known as Static Site Generation (SSG).

Don't worry, there's only one more acronym to come!

The downsides of a monolithic CMS

As a team, we have designed and built hundreds of custom websites, using a variety of monolithic CMS applications. We've spent years crafting our techniques and processes to get the most out of these traditional, open source CMS products. Their all-in-one, monolithic structure has served us well. But there are so many inefficiencies under the hood which are crippling their ability to provide a modern digital experience.

The monolithic CMS relies on a web server to host the application and website front end. There will be a separate server to host the database. So a request from a visitor to your website would go something like this:

1. The user's request is routed to your web server.

2. Request is processed by Apache or Nginx before being directed to your CMS.

3. CMS application interprets the request (commonly using PHP).

4. CMS follows logic in its own code to build the page using the server's resources.

5. CMS fires queries at your database server for configuration data and content.

6. Database server has a similar process, before running the query (often MySQL).

7. CMS takes the database response, computes it and assembles the page.

8. CMS responds to Apache or Nginx.

9. Apache or Nginx responds to the original request from the user's browser.

Remember, this is a single request from one visitor for a web page. Although some of those steps may take milliseconds, they all add up to significant waiting time and plenty of opportunity for bottlenecks.

We've had to pass through multiple servers, used a number of different programming languages and processes, made a lot of connections and consumed unnecessary bandwidth (which costs). Each step and interaction creates an opportunity for performance snags, failure points and potential security exploits.

How does the headless CMS and SSG compare?

OK, so here's how the same request is handled with a modern, headless CMS and SSG set up...

1. The user's request hits your web service provide (e.g. AWS).

2. Web service provider interprets the request to uncover the relevant file.

3. Web service provider responds with a static file (your pre-built web page).

Job done.

When an editor publishes content changes or a new page from the headless CMS, the content is stored in the cloud; usually in a simple, light, fast and easy to query format such as JSON.

A trigger (web hook) is hit to instruct the "build process" to start. The code from your SSG calls the APIs of the headless CMS to pull in your content and builds your web page. This page - which is also optimised to a far greater level from a code point of view, but that's for a whole other article - is stored as a static file in AWS.

Each request from a browser to see your web page now only needs to retrieve the static file from AWS. No processing overheads, logic, database queries, connections across multiple servers, etc.

This is a top level view of a headless CMS set up in diagrammatic form. It highlights the flexibility of using APIs for different purposes and the separation of the dark blue boxes (the presentation layer seen by users) from the rest of the processes.

With a Static Site Generator sitting on top of a headless CMS, this would have the additional benefit of having made all of the necessary API requests and page builds (filling up the "www" box with your website's pages as static files) long before the user's browser makes a request to see the page.

When that request does come in, it's just a case of pulling static files out of the "www" box and returning it to the browser.

Key benefits of the headless CMS and SSG set up

Scalable & cost effective infrastructure

Imagine hundreds of thousands of users hitting a website built around a monolithic CMS. The number of processes, servers and connections involved create numerous bottlenecks, so you now need to scale. You've now got to spend your way out of the problem by adding load balancers with more powerful and numerous web and database servers.

Of course, you'll also be hit by the additional bandwidth costs associated with this approach. Each connection represents the transferring of data, which represents a point for bandwidth charges to pile up.

Conversely, the service providers (such as AWS), will charge pennies for the hosting of static files and the running of build processes. Your bandwidth costs will increase with your traffic but you're only paying for the delivery of a static file (not the passing of data between multiple servers and the significant resources needed to build pages on the fly for each page view on your website).

Security considerations

The monolithic CMS set up provides hackers with a number of attack points to get at, steal, destroy or hold your data to ransom:

• Your open source CMS application's code is available to the hackers and they will know the exploits for the version you're running.

• Apache or Nginx, PHP, MySQL will all need to be routinely patched and upgraded to ensure known vulnerabilities in the versions you're running are not exploited.

• Your web server(s), database server(s) and the connections between them provide an attack point for hackers.

• CMS plugins, commonly used to quickly and easily add functionality to your open source CMS, will include vulnerabilities and will routinely "talk to" the creators' own web server.

For the statically generated site however, there are only static files. That's it. The headless CMS, the build process (including the code used in this process), are all securely stored and handled behind the scenes, completely detached from the AWS file storage serving the rests to the outside world.

Faster design and development workflows

Greater results usually take more effort, right? That's what we're taught from a young age. You get out whatever you put in; so we're told.

In our world of website design and build, the more you can automate and the less repetitive tasks or duplication you need to do, the more accurate and faster the results will be.

Approaching your design system and build processes with the same, reusable definitions and components in mind (using a framework such as Tailwind), coupled with a SSG (such as Gatsby), enables us to automate the handover from design to development and ensures pixel perfect representations.

Why are the Core Web Vitals so much better?

In the most simple form, the code used by the SSG which builds your web pages is structured around web components (individual blocks of content if you will).

Each of these web components represents a content block or module on your website and each will only carry just enough code (HTML, CSS, JS) to present itself in the browser. Nothing more.

Why should I care about Core Web Vitals?

Google obviously doesn't disclose the details of their algorithms. However, they have announced an update is due mid-June 2021 that will focus on the Core Web Vitals of the websites they index.

Websites with stronger Core Web Vitals save Google billions of dollars. Their performance has a significant impact on Google's ability to continually crawl trillions of pages across the web. These websites will also provide a greater user experience.

By adding more weight in their algorithms to the websites demonstrating strong Core Web Vitals, Google will be promoting the websites which provide benefits to them and the users of their search engine (maintaining the quality of their search results).

Create a digital customer experience that delights

If you're looking to enhance your digital offering to keep pace with today's extraordinary speed of change, and to better connect with your customers as behaviours evolve, talk to us.

We have a suite of strategy based products based solely on clearly defined tasks and outcomes to supercharge your digital experience. Do get in touch to find out more.