What is a Headless CMS?
This short blog outlines the evolution from classic content management systems towards modern-day Headless CMS stacks.
What is a Headless CMS?
The use of Headless CMSs has grown in popularity in recent years. This short article outlines the evolution before outlining some of the key benefits of the approach.
Classic CMSs represent the primary method of delivering content management for many sites today, especially those that are a few years old.
The basic setup is an application that holds the content and allows the marketing manager to manage it (the CMS), which you host yourself or via a third party on a dedicated server like those offered by Digital Ocean or Linode. That application can pull content out of the database via a template language that compiles it down to HTML.
Template languages like Twig, Blade, Liquid, or Handlebars are usually simpler than using a raw back-end language and help front-end engineers to create the front of the site without having to learn the entire back-end ecosystem.
Sometimes there is no middle layer, WordPress for instance ships with PHP templates by default. This means you are mixing PHP directly in with HTML, which in short can lead to confusing and less-performant code.
In terms of what end-users see, it’s just like any other CMS or online application - they go to a URL (usually something like mysite.com/admin), log in and edit content using forms.
Because the CMS itself is busy processing the template language and rendering the content, on top of updating content when someone edits something, the load on the server can sometimes balloon quickly. This means response times can slow down, and the front-end users can start to notice the site feels sluggish.
On top of that, pages can be slow to parse and compile down to HTML, front-end developers may not fully understand how to write performant database queries but are being asked to when using the templating layer, or sometimes the pages are just big and full of content.
To solve this bottleneck frequently a modern CMS like Craft or WordPress will use a caching system (usually via an add-on). This typically saves the resulting HTML down to a flat file on disk, which can be fetched quickly the next time the same request comes in. Whilst the end-result can be super fast for your users, setting up caching and getting it to invalidate properly can be tricky - oftentimes content editors end up publishing something in the CMS but not having it live on the site and have no idea why.
From a marketing perspective, there can be additional issues ranging from poor admin interfaces, difficulty updating complex types of content, security vulnerabilities due to third-party add-on’s etc.
There is also a natural evolution when it comes to B2B SaaS companies that outgrow legacy systems and are keen to upgrade to the latest cutting-edge CMS technology.
We use the term headless to describe the next group of CMS’ because they come without a templating and rendering layer - they have no way to send fully-formed HTML to the browser, and don’t expose routes by themselves (e.g. /blog/my-post) at the primary domain.
Instead, they operate isolated from the front-end of the site and expose only an API for developers to interact with. At this point, developers can choose a myriad of different ways to get the content from the CMS to the front-end of the site. The quickest route is to call the Headless CMS API live in the browser, but this leads to endless spinners and loading states as content downloads.
Usually, the front-end codebase will make the API calls it needs to as part of a build process - this process only happens when needed, like when content changes in the CMS or when code has been updated by the dev team.
Once the build process has been run and produced all the HTML as flat files, those files can then be served up to the users very very quickly. They can also be easily deployed to global CDNs and replicated on servers physically near end-users.
There is also the bonus that the front-end is decoupled from the back-end, meaning you host both applications on more specifically appropriate hardware, and can also swap either part out for a new one with a lot less risk.
Implications for Marketing
In terms of how this applies to the marketing team, in one sense there is little difference if the content modelling is done properly - you can build great and terrible sites on both systems!
The main upside for headless though is that the end-result website will likely be faster because using a headless CMS lends itself to a build process that produces flat HTML files which can then be cached and deployed on a CDN.
When it comes to changes in the content model both systems will require a developer to do something - but in the headless model it can be a lot less error-prone to roll out changes, resulting in fewer upsets or “site down!” calls.
However, there are trade-offs that you need to be aware of. You are essentially separating the two core components. You will thus need a developer to design the front-end of the site, as the marketing team primarily focuses on the content side. It is also best suited to teams that are scaling up and are looking to add more content and pages and want to do so while allowing free rein to designers to focus on the design. For growing B2B SaaS companies, looking to take their company to the next level, a Headless CMS like Contento represents an attractive option.
Of course, it’s not quite as simple as the binary split as we’ve made it out to be here. You can self-host your own headless CMS and there are plenty of SaaS offerings that deploy classic CMS solutions for you. This split is simply helpful to use when thinking about the two camps, as most often they fall into these two configurations.
Co-Founder / CTO