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

Tim Dodd

Head of Product & Technology

Looking at the world of headless versus monolithic CMS solutions

In this article, we'll cover off how you select your website's Content Management System (CMS), the difference between a monolithic and headless CMS, the drawbacks of the monolithic CMS applications we all know and love(d), and the tangible benefits of a headless CMS coupled with a Static Site Generator (SSG).

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 CMS you choose to build your website around is a crucial decision, and 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 quicker website design and build, lightning-fast website performance, and flexible content authoring to help brands tell their stories 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 website flexibility, not to mention increase security.

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 been spent, for everyone, before anybody even requested the page. This is known as Static Site Generation (SSG).

The downsides of a monolithic CMS

As a team, we've 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:

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

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

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

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

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

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

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

  • CMS responds to Apache or Nginx.

  • 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 wait 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...

  • The user's request hits your web service provide (e.g. Amazon Web Services (AWS)).

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

  • 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 JavaScript Object Notation (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 an SSG 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.

Total Economic Impact of switching to Storyblok

Forrester Consulting Audit

ROI over three years from switching to Storyblok

< 6 mths

Payback for resource invested in switching to Storyblok


Gains in team productivity after switching to Storyblok

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 rest 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.

In our world of website design and build, the more you can automate and the fewer repetitive tasks or duplication you need to do, the more accurate and fast 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 an SSG (such as Gatsby), enables you 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 its algorithms. However, it announced an update for mid-June 2021 that focussed on the Core Web Vitals of indexed sites.

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 algorithm weight to the websites demonstrating strong Core Web Vitals, Google is promoting the websites that benefit it and its searchers (maintaining search result quality).

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 on clearly defined tasks and outcomes to supercharge your digital experience.

Continue reading


Are you ready to make a digital step-change?

We believe that moving too slowly in digital is the biggest risk your business faces. If you are ready to move faster in digital, we are here to help.

Get In touch