If you search for the term “headless cms” you will find 50 products in a few minutes. This is a sign we might be at the peak of the buzz about “headless”. In the last 5 years, there was a myriad of such solutions added to the already crowded content management market. How does anyone navigate this space with such a number of options?
Before we dive into this mess and make some sense out of it, let me first try to define what headless is.
If you take an average headless CMS nowadays and you want to name one main distinguishable feature, you will probably say it has “(just) an API” for delivering content. You might say it’s API first, API driven, etc. But there is a multitude of other kinds of API driven systems which could also be named that way (CRMs, ERPs, DAMs, PIMs, searching, caching, ..), so why is the name headless mentioned only for CMS-es?
I would guess it comes from the fact that a CMS is/was a layer that usually delivers HTML markup to the end-user making it a kind of a head for that web site. The term headless communicates that a particular CMS doesn’t manage the end-user touchpoint.
Why would someone intentionally remove this part of the CMS? Well, almost 10 years ago the mobile was on a fast rise. On one side there were traditional CMS-es that were able to deliver HTML but (usually) not well-structured content.
Before mobile, traditional CMS-es were focused only on the web as a channel, the content was very much dictated by HTML if not stored directly as HTML. With mobile apps emerging and other possible interfaces on the horizon, like watches, glasses, and other smart devices, most CMS-es were not equipped with flexible and structured content models 10 years ago, heck, a lot of them are not ready now in 2020.
For example, the most used CMS in the world, WordPress, started as a blogging platform, and even though it is quite feature-rich, with many community extensions and many different usages, it still stores content as HTML. WordPress out of the box is not enough for today’s multichannel challenges, but its community is huge, therefore a lot of 3rd party efforts exist that try to counter these problems (e.g. Altis and similar).
The other juggernaut, Drupal, also wasn’t well equipped in the early days, but through community effort like the CCK extension, a possibility to manage structured content with custom content types was introduced in the core of Drupal 7 in 2011.
Unlike many other products, eZ Publish, a CMS we at Netgen are using for our projects, had these capabilities in the core since version 3 launched in 2002, but back then this was not widely recognized as an important feature.
Mobile was not the only force behind the push to headless. This was also fueled by the Software-as-a-Service business model. One of the first, if not the first, headless CMS was Contentful. It started as a solution for handling content for mobile apps, as there were not many options for that with traditional CMS, it soon turned to become a SaaS product leading the headless CMS market since.
The other force propelling headless in recent years is the whole client-side (javascript) development movement. More and more power and features were provided by browsers so more and more developers implemented features on the client-side, especially for web applications (think Gmail) which also spilled into website projects.
To summarize: Headless CMS is an API-first solution that provides channel-agnostic content management and delivery. Sounds clean and simple, but in reality, things are messier.
Headless vs traditional / monolithic
Complete opposite of headless CMS’es are the traditional ones, especially those which don’t have any usable public API available. That kind of products have all their features tightly coupled, focused only on web as delivery and ill-equipped for multi-channel support.
There is a clear distinction in capabilities between traditional and headless. If you still just need a website you are probably better off with a more traditional CMS as you don’t need to develop the “head”. If you do use one, choose the one which has a sound API, just in case. If you want to decouple content from the end-user touchpoint then you will probably have more success with a headless CMS or a CMS that can work in headless mode.
On a side note, a lot of traditional CMS’es also neglected editorial experience for many years resulting in frequent frustration by editors. Headless CMS, on the other hand, were built from scratch and could focus on better editorial experience. But even though headless CMS might have excellent experience for most common use cases like content entry, the experience might still be limited (e.g. no preview). Content management is not just about content entry.
Headless systems in many cases emphasize their performance as an additional gain over traditional ones. Although it is true you can make a very fast site with JAMstack and a headless CMS, you can do a fast site with traditional CMS as well, leveraging CDNs, reverse proxies, caching strategies, etc. On the other hand, transferring code from server to client doesn’t guarantee good performance. Code on the client side is harder to manage, different browsers provide sloppy ground and you can make badly performing client side code as well. Btw, speed is not just about web delivery performance, it is also about how fast you can create content or do code changes.
Headless vs hybrid / DXP
Some traditional vendors turned hybrid by adding APIs to provide a “headless” option. This might prove important in the long run to keep existing clients but also attract new clients having features for both worlds. Of course, the process is not simple. Adding a sound and usable API is not a straightforward thing to do. There might be a lot of technical debt which might get exposed through the API and cripple the usage and developer experience. The other thing is the above-mentioned content model flexibility and channel-agnostic content storage. If the existing content repository is rigid and storing only HTML it might prove impossible to create a meaningful API on top of that.
Also, there are ways to integrate and mesh things without an API. In the old days we would use SSI to assemble pieces of a page, then came ESI which did the assembling on reverse proxies, today you can do this on the front side with solutions like inertiajs.com or Mercure / SSE.
An additional obstacle for hybrids is the required talent. New kinds of architecture and technologies require adequate knowledge to leverage it. You can’t just learn new stuff with a snap of a finger.
The term hybrid might not be marketing friendly, you probably heard more acronyms which are describing the same thing, but looks like DXP (Digital eXperience Platform) is the winner. Gartner has now a DXP magic quadrant instead of CMS. The DXP emphasizes that the system should be a focal point of various digital touchpoints, not just the web, providing APIs and tools for making those touchpoints.
Categorising the mess
I did a quick classification of 90 content management systems from a list I compiled quickly for the purpose of this post. At least 60 claim to have some sort of API, but not all of them are headless. Some are existing content management systems with added API and some are API-first with a decoupled front layer.
Here is how I see the market today:
An approach to organising the headless marketplace as it looks today
From a usage point of view there are:
Traditional web building CMS’es
Hybrid, meaning there is an API and tools/ways to build a website
Pure headless or CaaS
From an architectural perspective there are:
Monolithic, traditional CMS’es, potentially with some API
Decoupled, either traditional CMS’es that can work in headless mode, or headless CMS’es with tooling for building a web site
Pure headless
So, we have very interesting options to choose from, based on your project and overall strategy. Important to note is that my classification is based on vendor offerings. Keep in mind that there are a lot of implementing agencies which bring additional value to the market with their attributions, extension, integrations and best-of-breed bundles. This is especially true with decoupled products as they are by nature more open for meshing.
On the topic of decoupling
There are two market forces currently present. Preston So is Senior Director, Product Strategy at Oracle and he called it a war in this article earlier this year: Off to the digital experience races: The second CMS war is officially here
Due to headless use cases gaining in popularity traditional CMS’es are forced to add sound APIs and try to decouple themselves in some way
On the other hand, some headless CMS’es might go in the opposite direction and add web site tooling or intentionally leave this to 3rd parties (will mention those later)
Common for both forces is decoupling - breaking monoliths in smaller parts. It is known, even from ancient “Divide at impera” — smaller pieces are easier to replace/test/evolve. We can also relate to the object oriented paradigm “separation of concerns” — Smaller pieces are easier to inject and integrate into existing solutions.
Important to note is that complexity of a solution using decoupled parts is not lesser than of a monolith, it is just different. Decoupled architecture requires adequate intercommunication, often asynchronous, and that is not trivial to build nor maintain.
Also, the point with decoupled architecture is to handle all parts as independently as possible. If you just interweave all decoupled components in an interdependent mess it is not better than a monolith, it is even worse.
The different flavors of headless CMS
From the 90 content management systems at least 50 have some SaaS offering. Although you would expect that headless CMS’es are mostly in SaaS, a good portion have an “on premise” version, some actually don’t have SaaS offering at all.
There are situations where you want to be in full control and have no limits in customizations and extending — so the “on premise” could be a better choice. There are even some mixed options: the content repo being in the cloud and the interface for editing is open-source, like with Sanity.
Interesting to note that around 50 out of 90 are fully or partially open-source, and yes, there are full open-source headless content management systems.
Finally, there are some distinctions on the API level. When we say API in the CMS context nowadays we mean RESTful API. SOAP and similar are hardly to be seen, on the other hand GraphQL is gaining in popularity. What I didn’t see so far but might be interesting to have is some kind of server push possibilities like SSE. Important thing to look for is the existence of SDK which speeds up development with the API. Most vendors should have some Javascript client side helpers at least, but more mature vendors have more languages supported. If no SDK, then at least they should have the API support OpenAPI or JSONAPI specs so you can build the client wrapper easier.
Advantages of headless CMS’es
There are many good things about a headless approach. Headless CMS’es are multi-channels by nature. This means it's easier to COPE — create once publish everywhere, because it forces you to focus on reusable content and avoiding delivery context. This enables quicker changes across channels, if you set up your content governance appropriately.
Scalability is easier as you deal with smaller pieces in your architecture. If the bottleneck is just content editing, you can scale it without touching other parts.
Related to that, performance could be potentially better if done right:
simpler caching between presentation and application layer.
less server demands due to some of the complexity transferred to the browser.
A popular approach is to have static sites and get a very fast site. Although this idea is not new, we witness a strong renaissance of static site generators in the market.
Disadvantages of headless CMS
As with any buzz, there is a chance to be influenced by the shiny object syndrome :)
You see the new thing that promises to solve your problems and you jump right onto it. Headless CMS do solve some things better than traditional, but they also have their own problems.
When researching this topic I came across a sheet with a lot of headless CMS’es listed and compared feature wise.
A screenshot of the headless cms comparison sheet - it’s maintained via Github
I’m not sure if it is up to date but it’s still interesting to see. It reveals how many of the standard CMS features are not there. The CMS’es might be perceived like a commodity after so many years, but the fact is that systems became quite powerful products. I am not even talking about fancy DXP features, I talk about core content features like:
Search
Media management
Multi-language
Workflows
Scheduling
Versioning
Handling edit conflicts
Taxonomies
Custom content modelling
Those are possibly “missing in action” if you consider an average headless CMS. Sure, for some you can find a decoupled option (DAM, search systems), but the rest are very core. You need to be careful not to fall in the trap and later not be able to have those features because the CMS is not extensible nor customisable.
See past the hype and choose what is better for your project and strategy in the long run. New does not mean it is always better (for you).
Headless CMS have limitations, especially cloud based, in terms of customizations. You need to be aware of what kind of resources you need to implement for your project. There are more and more JavaScript devs but not sure if those numbers match the demands. Maybe you can solve your needs with good old PHP dev. Not everything with the JAMstack and fat client approach is peachy.
Even if you choose to go with the headless, there are several things to be aware off:
You might end up with more editorial interfaces than before. This might be ok for larger organizations with more people on the team with different roles, but could be bad experience for smaller teams
Asynchronous integrations are adding complexity, not reducing it. Too many moving parts are not easy to handle
Due to different architecture switching cost could be high
Finally, what about the head?
Once you find the best headless CMS that fits your project’s strategy, if your project includes a web site, you need to somehow implement the “head”.
“Head” features are everything a common web site usually has for content delivery and more:
Generic HTML rendering
URL mapping and management
Navigation management
Page building and preview
In-context editing
SEO features
Accessibility compliance
Metadata / Microdata / Open Graph and similar
Caching on various layers
If you use headless CMS you will need to implement those features yourself — and reinvent the wheel — or use another decoupled 3rd-party product for the head!
Head for headless
Five years ago, we at Netgen were thinking about making the content delivery part as a separate layer decoupled from a content repository. The result today is a standalone enterprise open-source product — Netgen Layouts. At the beginning it was hard to explain what we were doing as there was no similar product in the market. Only in 2019 I started to notice some products communicating: “Have a headless CMS? Here is a head for you”. There is now a completely new kind of product category which doesn’t have a name yet. I use the term “head 4 headless”. I heard Deane Barker uses CPMS (Content Provider Management System), some others use FPM (Frontend Platform Management) or FaaS. More importantly, it became a topic.
Static site generators are trying to fill this gap as well, like Gatsby, offering great performance for web sites, but potentially very poor build speed — any content change requires rebuilding of all static files which can take a lot of time depending on the size of the site.
More and more solutions are coming in this new space. It is great to have more options, but you need to understand the pros and cons of each solution to find the best fit.
To conclude this piece, here are my final recommendations:
consider your overall strategy, where are you going with your project(s)
analyse what kind of architecture you need and research which products fit (unfortunately there is no better way than to try it yourself or find someone insightful you can trust)
try not to reinvent the wheel
Don’t lose your head ;)