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.

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.

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.