Posted: 5th June 2020 by Angus Gordon
If you work in content, you’ve probably heard of headless content management systems. Perhaps there’s a vendor giving your organisation the hard sell on a headless CMS right now. Perhaps you have a developer in your team who waxes lyrical about how much easier and more fun their job would be if you went headless. Or perhaps you’ve simply come across this strange term in your reading and wondered if it’s something you’re supposed to know about.
There are lots of blog posts out there purporting to give an introduction to headless, but they’re mostly aimed at developers, written as sales material by headless CMS vendors, or both. This is a problem, because it’s us content people who have the most impact on the success or failure of a CMS implementation – and who will be most affected by it.
So my aim in this post is to offer a simple, unbiased introduction, aimed squarely at fellow content folks. You won’t find a single reference to ‘GraphQL’ or ‘the JAMstack’, I promise.
What’s a headless CMS?
To get our heads around headless CMS, let’s first think about the other kind of CMS, often called a ‘traditional’, ‘monolithic’ or ‘legacy’ CMS. I’ll go with ‘traditional’.
A traditional CMS has 2 parts:
- A back end allowing authors to add and edit content, which is stored and managed in a database.
- A front end (otherwise known as ‘the website’), where your users go to view that content.
A headless CMS, on the other hand, looks like this:
- A back end allowing authors to add and edit content, which is stored and managed in a database.
- There is no part 2.
Get it? A headless CMS comes without a website attached, like a headless body comes without a head attached. (Back end, front end, body, head…I admit the metaphor could be cleaner, and less grisly.)
With a headless CMS, you build your website (or other content channel) separately, and it runs independently of the CMS. The website gets content from the CMS using an API (Application Programming Interface), which is just a way for one piece of software to talk to another.
The last few years have seen headless CMSs take off in a big way, with systems like Contentful, Prismic, Sanity and Kentico Kontent entering the market and attracting big investments from venture capital firms. At the same time, traditional CMSs like Drupal and Adobe Experience Manager have beefed up their own headless capabilities, claiming to offer the best of both worlds.
But why? If a traditional CMS gives you a back end and a front end, isn’t that a good thing? Why build a website from scratch when you can get one for free with your CMS?
Benefits of headless
When you think about it, there are lots of situations where people use more than one piece of software to complete a task. For example:
- An author writes a manuscript in Microsoft Word, then hands it off to their publisher, who uses desktop publishing software like InDesign to prepare it for publication.
- A photographer stores, catalogues and tags their photos in MacOS Photos, but when they want to do serious photo editing, they fire up Photoshop.
In other words, we choose tools that are fit for purpose, even if that means switching horses midstream. Headless advocates say that a piece of software can be great at managing content or presenting content, but the same software can’t be great at both. Let’s look at some of the reasons why.
Developer experience and flexibility
For developers, it’s a pain to build a website using the front-end tools provided by a traditional CMS – or so they tell us. Every CMS has its own way of doing things, there are no common standards, and all of them struggle to keep pace with new tools and trends.
A headless approach lets developers use state-of-the-art web frameworks like React to create user experiences with more interactivity and pizzazz than a traditional CMS allows. And because the CMS doesn’t dictate how the website is built, developers are free to reuse the same front-end toolkit across projects, regardless of which CMS is serving the content.
You probably have to be a developer to feel this in your bones, but the lure is real and accounts for much of the success of headless to date. If you’re being sold hard on the headless option, there’s a strong chance it’s because a developer has fallen in love.
Multichannel publishing
This is the big one for us content people. If you want to use the same repository of content to serve a website and an app and a chatbot and an information display, there are real problems with using a CMS that’s tightly coupled to just one of those things.
A headless CMS imposes the discipline you need to create well-structured, reusable content. It requires you to do the hard thinking about your content model before you start creating content. It then allows each presentation channel to fetch, filter and configure content in its own way.
Performance
Websites built with traditional CMSs are often slow to load. One reason for this is that they build web pages ‘on the fly’, with content requested fresh from the database every time.
By switching to a headless approach, you can have a lightning-quick website even with relatively cheap hosting, especially when you build the front end using a static site generator. A traditional CMS site can use caching and other tools to get some of the way, but it’s never going to be as fast as a static website.
Security
Traditional CMS websites require frequent security updates to protect them from hackers. Headless CMSs, on the other hand, keep your precious database ‘quarantined’ from the website’s front end, making it much harder for would-be intruders to find a way in.
Drawbacks of headless
If headless CMSs are so great, why doesn’t everyone use them?
As it happens, headless hasn’t been the global smash hit that you might expect from listening to its boosters. According to CMS expert Preston So in this fascinating talk on the future of CMS, not only has adoption of headless been slower than expected, but some organisations that went the headless route are now having buyer’s remorse.
So what are the drawbacks?
Reliance on developers
Remember when I said that using a headless CMS means your website is built and managed independently of the CMS? Well, you’re going to need a developer for that, and for every improvement you ever want to make beyond a simple content change.
If you don’t have ready access to a team of front-end developers, either in-house or via a trusted external vendor, don’t even think about going headless.
And it’s not just access you need but a strong collaborative process. Without a pipeline that enables continuous improvement that can flow between UX, content and developers, you’ll be in a world of pain any time you need to create custom content – for example, when you’re launching a new campaign.
Decoupled means decoupled
You know how, when you’re logged in to a CMS like WordPress or Drupal, you can edit any page on your website by going to the page and clicking an ‘edit’ button? Well, you can’t do that with a headless CMS. Remember, the CMS and the website are totally separate things.
If you go headless, be prepared for complaints from content authors used to tight integration between the front and back end. The tradeoff might be worth making, but we can’t pretend it’s not a tradeoff.
Less control over presentation
By its nature, a headless CMS gives you control over your content, and only your content. You don’t control how a given piece of content is laid out on a specific web page, because that’s no longer the job of the CMS.
Many of us in the content strategy world, especially those of a structural bent, think of this as a good thing. Let’s separate content from presentation, we say! Content is data! Kill WYSIWYG!
But that message can fail to resonate with content creators who have become used to drag-and-drop tools that offer sophisticated control over layout without the need for code. We fans of structure might want the CMS to be more like Excel; they want it to be more like Squarespace.
Is headless right for you?
Looking at the big picture, there’s no doubt that the world of digital content is moving in a headless direction. The proliferation of new content channels makes that inevitable. And there are new products like Tina CMS trying to address some of the drawbacks I mentioned above – so they probably won’t be drawbacks forever.
But that doesn’t mean traditional CMS is going away any time soon. 37% of websites are still built in WordPress, after all, and enterprise-grade traditional CMSs like Drupal are still holding their own.
Should you go headless? It depends. If you want to reuse content across multiple channels, or your content is presented within an app or an app-like experience, you should absolutely give a headless CMS your serious consideration.
Even if those things aren’t true, there could be a case for headless if it’s been recommended by a vendor you trust and want to work with. Just make sure you consider the drawbacks as well as the benefits.
If you do decide to go headless, the success of your project depends on a robust, flexible, well-tested content model, so make sure you have a content strategist with extensive content modelling experience on the project team. (Hint, hint.)
But even if you stick with a traditional CMS, think about what you can learn from a headless approach. How might you benefit from ‘decoupling’ your content from a single form of presentation, even if you just have a website?
You can start very simply: whenever you publish a page, check how it looks on a phone, not just a desktop computer.
The more you think about content as structured, modular and reusable across different devices and channels, the readier you’ll be for a transition to headless, or whatever ‘grand compromise’ (in Preston So’s words) the future of CMS brings.
Set up your CMS for success: talk to Weave about content strategy and content modelling
