Why brands must think ahead and embrace the headless CMS

Choosing a Content Management System (CMS) should be one of the first considerations for a content or marketing team, and getting it right can be critical

A hasty or ill-informed choice of CMS can lead to lengthy delays in website projects, inflexible configurations, and constrained content authors, administrators and developers. The result is a stale and under-performing website.

Gone are the days of monolithic CMS architectures. Today, maturing headless CMS options provide fast website design and build, rapid website performance, and flexible content authoring to help the brand tell their story in an almost infinite number of ways.

Unlike monolithic CMS applications (think WordPress, Joomla, Kentico), headless CMS solutions detach the code for front end presentation and web page delivery to the browser from the administration and content / data storage. This drastically improves the flexibility afforded to a website, not to mention increasing security.

A headless CMS allows you to optimise website performance by using the APIs within clever build processes. This can be used to request each page of your website and automatically create (the ‘build’) and store them as static files on a scalable storage solution (e.g. AWS Amplify / S3). This delivers lightning fast performance, allowing pages to be served before users request them. This is known as Static Site Generation (SSG).

At Mediablaze 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. But times have moved on and there are many inefficiencies under the hood which are crippling their ability to provide a modern digital experience.

Monolithic CMS applications provide an all-in-one solution, with the application dictating the content authoring and administration experience also managing the storage and access to data, configuration and content. It includes the code for the front end presentation in the browser too.

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. This means a single request from a visitor to your website entails numerous steps, with each one increasing the risk of performance snags, failure points and potential security breaches.

However, a headless CMS simply registers the user's request, and the web service provider interprets this to uncover the relevant file, responding with a static file (your pre-built web page). Simple.

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 is stored as a static file in AWS. Each browser request to see your web page now only needs to retrieve the static file from AWS. Simple.

A SSG sitting on top of a headless CMS has the added benefit of having made all of the necessary API requests and page builds long before the user's browser makes a request to see the page.

Unlike for a monolithic CMS with its numerous processes, servers and connections — not to mention additional bandwidth costs (each connection represents the transferring of data, which represents a point for bandwidth charges to multiply) — service providers (such as AWS) will charge pennies for the hosting of static files and the running of build processes.

The monolithic CMS set-up provides hackers with a number of attack points to steal, destroy or hold your data to ransom: your open source CMS application's code is available, as is your web server(s), database server(s) and the connections between them. Your Apache or Nginx, PHP, MySQL will also need to be routinely patched and upgraded to avoid exploitation of known vulnerabilities in the versions you're running.
CMS plugins will include vulnerabilities too, and will routinely ‘talk to’ the creators' own web server.

The statically generated site is more secure because it only contains static files. The headless CMS and 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.

The more you can automate, and the less repetitive tasks or duplication needed, the more accurate and faster the results will be. Therefore, 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.

In its most simple form, the code used by the SSG is structured around web components (basically individual blocks of content). 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.

Since June 2021, these Core Web Vitals are central to how Google indexes websites, allowing it to promote the websites which provide most benefits to both Google and its users.

Choosing the right CMS is critical to today’s brands. Don't get left behind.

Talk to Mediablaze

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.