Headless content management systems – they’re all the rage. With a market growing at a rate of over 22 percent per year, according to ReportLinker, headless CMS is increasingly the format of choice for e-commerce companies, news organizations and others who deal with a revolving door of content delivered across multiple platforms.
So what, then, is a headless CMS?
In short, it’s a back-end-only content management system that is not coupled with any front-end presentation layer or “head”. Also referred to as a decoupled CMS, a headless CMS exists primarily as a content repository, transmitting content via an application programming interface (API) to whatever channels the content is aimed at.
Since the birth of the Internet, the vast majority of CMSs have been of the “coupled” variety (the kind most readers will be familiar with), wherein content is uploaded to a back-end and is then automatically transmitted to a pre-built front-end delivery layer. This format has obvious advantages, namely its simplicity – anyone with basic CMS training is able to create and update a website’s content and the front-end is standardized, making it easier to build your website quickly.
However, with the advent of mobile apps, chatbots, the Internet of Things (IoT) and other innovations, many companies and organizations now expect the information on their CMS to be able to do a lot more than just exist on a website. For many, the page layout systems offered by traditional CMSs are a constraint to developers and marketers and can impede the adoption of new third-party technologies.
The case for decoupled architecture
In a headless CMS, front-end developers have free rein to build as many “heads” as they want for as many channels as they want to deliver content to. While this may require more IT expertise on the client end, due to it being harder to preview content, there are numerous advantages to this structure.
From a scalability standpoint, the advantages of a headless CMS are self-evident. In a traditional coupled system, CMS code is tightly connected to a particular set of templates, which means that expanding to new platforms such as native apps or digital signage involves a great deal of customization and installations on the part of developers. By contrast, with a headless CMS, there are no limits to the platforms that can be added.
Speed and Scalability
In the case of a rapidly expanding business, a traditional CMS places constraints on a website’s capacity to expand. Adding discussion forums, AI chatbots, and other add-ons all mean additional server requests, which in a traditional CMS will slow down the performance of the website while creating a messy patchwork of plugins. A headless CMS, by contrast, means you can offer increasingly diverse services without sacrificing speed and performance.
For companies and organizations that maintain different versions of a website for various languages, locations or franchises, a headless CMS can mean less stress over version control. Because all the content is stored in a single location, the headless format makes it much easier to keep track of what changes have been made where and when and allows you to push revisions out to multiple sites simultaneously.
If you’re a prominent news organization and you’re likely to have articles and videos going viral, you definitely want a decoupled CMS. With a traditional CMS, any sudden burst of traffic is liable to overwhelm the server and paralyze your site – unless you pay for hosting that will accommodate enormous spikes in bandwidth use. This is a non-issue with a headless CMS, where heavy traffic on the front end doesn’t impact the back end at all.
For retail websites, speed truly matters – sites that load in one second have an e-commerce conversion rate 2.5x higher than sites that take five seconds to load, according to Portent – and sites underpinned by headless CMSs are faster across the board. With coupled CMSs, loading a page requires the server to make dozens of automated requests, although advanced caching can solve many of these challenges when in the hands of an experienced team. A single request for a hand-coded HTML website linked to a headless CMS, however, will load in less than a second.
Headless CMSs also offer greater security. Sites with traditional CMSs are much more vulnerable to distributed denial-of-service (DDoS) attacks, in which hackers attempt to overwhelm a site by flooding it with superfluous requests – which with a headless CMS translates to a single request. Also, because the API publishes headless content as read-only, it can be protected by multiple layers of code, lessening the risk of attacks.
The case against
While a headless CMS offers great advantages in terms of scalability, stability and security, it also presents challenges and drawbacks and is certainly not suited to all organizations. A traditional CMS with its out-of-the-box front-end templates is advantageous for organizations that lack the internal IT capacity to develop front-end applications or the budget to hire outside developers to develop and maintain a custom solution.
A headless CMS is, by its nature, more complex and more expensive than a traditional CMS, requiring an upfront cost for the CMS, the development team, and the necessary infrastructure to run your website, app and whatever other tools are using the CMS. Headless CMSs also come with formatting challenges, as they do not necessarily allow you to preview what content will look like on the page, requiring extra steps.
For organizations whose websites are largely informational and static, and are unlikely to be suddenly overwhelmed with high demand, a headless CMS is not optimal. With a traditional CMS, the front-end is standardized, meaning that you benefit from existing templates for standard features like the user login page, search results page, etc. You also benefit from the accessibility and SEO work that has been done to optimize the standard templates.
When you build a custom front-end, on the other hand, you take full responsibility for all of these aspects of your website.
The best of both worlds?
For those looking for the scalability and stability of a headless CMS while still benefiting from the out-of-the-box front-end templates offered by conventional systems, a middle ground exists in the form of a hybrid or “progressive decoupled” CMS. As a decoupled system with a content-as-a-service (CaaS) API, a hybrid CMS enables content delivery across multiple channels while also offering marketers the types of interfaces they’re used to from conventional CMSs.
There are some disadvantages here compared to a fully headless CMS. It may be more difficult to take advantage of microservices and omnichannel delivery with a hybrid system versus a fully headless one, and it does not offer the same flexibility when it comes to publishing dynamic content on a multitude of platforms. It can also be more complex to maintain than a fully headless CMS due to the presence of both front-end and back-end code.
Nevertheless, for many organizations looking for high-performance sites with maximum speed and security while avoiding the hassle and cost of from-scratch front-end design, a hybrid CMS might be the perfect solution. You can seen an example of this in action with the work we did for Princeton International, whose curriculum planning tools were built with decoupled components.
Train your team – Decoupled Drupal with Gatsby
Drupal has long been associated with its flexible front-end theming system its content publishing features. This might lead one to think that Drupal isn’t the best choice for a headless CMS. However, since Drupal 7, it has been an API-first CMS that provides multiple ways for external systems to integrate with it and is in fact very well suited to a decoupled structure.
When Drupal 8 was released, the ability to function as a decoupled CMS was built into the core with the introduction of a RESTful web services API. This type of API, based on the representational state transfer (REST) architectural style, is ideally suited to building a decoupled site or integrating with an iOS or Android app or other web services.
Of course, some of Drupal’s much-vaunted front-end functionality (i.e. templates) is lost or inhibited in a headless setup, which will generally make it much harder to “preview” web content prior to publishing (previewing would require a custom preview workflow, like that provided by Gatsby). However, a hybrid setup will enable you to fully maximize the benefits of using Drupal while still benefiting from all of the advantages of a decoupled CMS.
Is a headless approach right for you?
When considering opting for a headless CMS, it’s important to consider how much time and energy (and budget) you have to commit to your web services. If you have the internal capacity for dedicated front-end development or the budget for ongoing external support in this area, a fully headless approach might well be right for you, especially if you’re dealing with dynamic content across multiple channels.
Conversely, if you’re not a developer and don’t have one on your team, and it’s important for you to be able to preview content prior to publishing, a headless CMS is probably not a good option. With that said, if you deal with potentially viral content and are looking to expand across multiple platforms, but still want to be able to preview content and take advantage of Drupal’s many out-of-the-box features, a hybrid solution might be a good option for your organization.