What is a headless CMS?

Quick definition: A headless CMS separates the presentation layer from the delivery layer of the content, allowing front-end developers to access content directly from the content repository via HTTP APIs, then deliver that content anywhere.

Key takeaways

What is headless CMS?

How did headless CMS develop?

What are some advantages of using headless CMS capabilities?

What’s the difference between headless and hybrid CMS capabilities?

What are some challenges when using headless CMS capabilities?

What is the difference between headless CMS capabilities and a static site generator?

How will headless CMS capabilities and architectures continue to change?

Q: What is headless CMS?

A: A headless CMS makes it easy for developers to accomplish their omnichannel content delivery goals. They can grab that content and deliver it anywhere. A headless CMS allows you to take content out of a CMS and deliver it to any front end using any tool that you want, and how you do that depends on which CMS that you have.

If you have a pure headless CMS, you will only have a content repository and nothing else. You can use APIs, you can pull that content out, but it doesn't have any presentation capabilities. If you do want presentation capabilities, you're going to have to build that UI or user interface from scratch. There are other CMSs you can purchase that have headless content management capabilities while also offering presentation functionality.

One example of a headless CMS use case is the creation of experiences with pure JavaScript applications as a front end, which are running in a web browser and being driven with content from a back-end system. There's no more HTML being generated on the server by the content management system. Companies may also use a headless CMS to deliver content to a mobile app, IoT device, chatbot, or voice assistant.

With such an architecture, experience management requires API’s over which the front-end application communicates with the content repository. Every headless architecture needs an API in-between the front-end application and the back-end content repository. The API is the gateway for a headless CMS implementation to fetch content from a backend repository.

A headless CMS approach can help to quickly deliver content to a variety of devices and channels, including web apps, mobile devices, and IoT devices.

Q: How did headless CMS develop?

A: Headless CMS capabilities are the combination of various trends coming together over the past several years. The first trend is the end user's constant quest for immediate results. Everybody wants immediate app-like web experiences.

The second trend is the increasing popularity of mobile devices. Mobile was the first channel that had nontraditional front ends where you would not send HTML to a browser just for mobile applications. Attempting to load a webpage on an early smartphone over a slow connection was a painful process, and developers began looking for a solution.

The third trend is the increasing availability of tools and front-end developers. Front-end developers work on client-side applications to render experiences. The number and maturity of tools available for front-end developers to create client-side applications has grown over the years.

Bringing those three trends together shows how there is a trend from server-side HTML rendering to channel- and purpose-specific rendering of experiences directly on a client.

One of the reasons for the fast growth in mobile applications is that mobile applications can often render content and content transitions very quickly. This and the growing number of front-end development tools now available are accelerating the adoption of headless CMS capabilities.

Q: What are some advantages of using headless CMS capabilities?

A: With headless CMS capabilities, in addition to providing faster web experiences, web developers have the flexibility of using tools and frameworks they are most comfortable with. They don't need to stick to a specific application stack for creating and rendering HTML. They can now create purpose-built applications for rendering content in a given use case or channel, using application programming interfaces, or APIs, for communicating with backend content repositories. Content APIs allow different technologies or platforms to communicate with each other.

Q: What’s the difference between headless and hybrid CMS capabilities?

A: A pure headless CMS architecture only offers a content repository and doesn’t have presentation capabilities. While this approach lowers the barriers for developers to quickly create or test a new experience initially, it requires updates to the presentation UI in the future to be made and maintained by developers.

Hybrid headless CMS, also known as a decoupled CMS or just hybrid CMS, is in between the traditional CMS domain, where HTML is sent to a browser, and headless CMS. It supports headful and omnichannel experience as opposed to just one channel. And it helps line-of-business users manage content across those domains while developers get the simple tools they need to access content directly for delivery to any endpoint - be it a chat bot, voice assistant or other IoT device.

With a hybrid CMS, you get everything you need for headless content management, and you get all this other functionality out of the box, so you don't have to build any of that functionality — like authoring capabilities, multi-site management, and language translations — from scratch. You can reuse content from your website in a headless manner, and that's not something that a pure headless CMS would do. Pure headless CMS isn't going to manage a multi-page website with all the robust functionality you need for a global website, and then also be able to reuse that content in a headless manner.

There are a lot of benefits to using hybrid CMS for supporting traditional as well as newer experience management approaches. And there is a sufficient amount of challenges with newer ways of creating web experiences, that many web content owners are opting to combine using newer technological approaches with traditional web sites and pages in ways that make business sense.

Q: What are some challenges when using headless CMS capabilities?

A: Challenges with headless CMS architectures, deals with organizational challenges. Content management over time can be extremely developer-centric in headless CMS scenarios. That is because content requires the engagement of IT developers in order to manage content experiences over time. Business users, like marketing employees, will typically not be able to make required content (or presentation) changes by themselves.

It will often be up to developers who created the application to make every change. And if developers are not in-house, if the headless CMS application was created by an agency, then any changes to that application and relevant content will have to be made by the agency. This can significantly slow down content operations at your company and increases the cost of updating or making changes to web experiences. This is another reason why a growing number of content owners use time and value-based metrics, over time, to decide where to use what kind of content management approach, and often end up with a mix of best approaches for different use cases and priorities.

Q: What is the difference between headless CMS capabilities and a static site generator?

A: Static site generators are exactly that - tools that generate static web pages or sites. At a time where the majority of web content is dynamic, and web experiences are driven by in-context analytics and personalization, economically viable use cases for static site generators have become limited. Sometimes they are used as demo examples to showcase headless CMS capabilities.

Q: How will headless CMS capabilities and architectures continue to change?

A: Rapid innovation will continue to be the only constant for headless CMS. Front-end frameworks will continue to evolve. Older tools will disappear, only to be replaced by newer and better ones. Their attractiveness for programming fast, channel- and purpose-specific client applications will continue to grow. For users this will continue to come at the cost of keeping up with the innovation cycles in this rapidly evolving area.

At the same time, larger enterprise solutions will incorporate more and more of the new approaches and utilities. They will seek to combine the benefits with cutting-edge web development with the requirements of content management on an enterprise scale.

The winner will continue to be end users, who will get to keep enjoying web experiences that get faster and more engaging all the time, regardless of which channel or on what device consumed.

Mathias Siegel is a Principal Product Manager for Adobe Experience Manager Sites. He oversees product management, including planning, prioritization, and working with engineering on building web content management features at Adobe.

People also view