Crownpeak vs. "Headless CMS": Differences & Similarities

This could easily sound like a Halloween post! Headless CMSes and cautionary tales Oh My! Alas, it's just basic IT, but maybe that is scary enough :)

So called "Headless CMSes", also known as "API-first", "API-based" or "API-driven" CMS platforms, have gained in popularity due to their simplicity and ability to isolate content authoring from page design. They allow your site content to be authored in simple forms, and the content is served up to the web pages via an API. One aspect of the Crownpeak CMS is that it can be used exactly like a Headless CMS, and the more advanced features like page previews, faster page loads due to pre-rendering and more sophisticated author ACLs and workflow are available if needed.

You can think of CMS systems as having two parts. The first is a content entry and storage system so authors can enter their content and have it available to the web pages on their site. The second part of a CMS is the delivery of the content, typically merged with the HTML for the site.

A Headless CMS focuses on that first part, providing easy to create forms for content entry, and the content is stored in a database. The content is made available through APIs, often on a Content Delivery Network (CDN) to help with performance. The second half of the picture is left as an exercise for the web developer. Typically server side code, or more commonly browser-based JavaScript code, is written to pull the page content in the HTML page shells.

Headless CMSes are useful when the web developer wants to have a CMS for content authors, but does not want to deal with the hassle of managing a CMS. Most of the Headless CMSes are delivered as a SaaS, so they can hand off that part of the web management to the other simpler system. This pattern is common for design oriented agencies.

The authoring side of the Crownpeak CMS works very similarly to a Headless CMS. Both offer a way to easily setup input forms and store the content in a database. Both offer an API and CDN for fast delivery of the page content.

Crownpeak, being a full featured CMS, allows the page rendering and delivery too, and can be used in both Headless and normal modes simultaneously. One example would be to have the CMS publish a page, but make the data available at the same time via API for a more dynamic part of the site or to another system.

Using an API to access the CMS data can be very useful in certain situations, but you should be careful about over-using that mode for content that can be static. If you have content that is the same for every user, it is better to build that right into the page, rather than pull it from an API for every page load.

Even if the content is brought in via JavaScript by the browser, the added processing for each page will be slower (especially on mobile devices), and caching can be an issue where it would not be for a static page. The parts of the page that need to be dynamic, where the content changes for every user, of course need to be delivered by server side or JavaScript code. So, the dynamic parts should be in code, but avoid making normally static page parts unnecessarily dynamic.

Pure headless CMSes also suffer from some other problems

One issue is that there is no preview as you edit the content. Since the authoring is decoupled from the page rendering, the authoring environment cannot show how the content will look on the page without some connection to a rendering system outside the Headless CMS. If you cannot preview the page, you may miss issues with text being too long for the parts of the pages, or images not looking right on the page (too big, too small, etc.).

Headless CMSes, at least in their current incarnations, often lack the extensive authoring ACLs and workflow that are common in full CMSes. These features may not be as important if you have a single author, but are very important for larger groups so you can control who can change which content, and work on multiple versions of the content before release.

Content silos are another concern for Headless CMSes. Typical corporate sites draw from many systems and typically have a full featured CMS alongside smaller projects that may use a headless CMS. Once that approach is taken, though, the content in the Headless CMS can become siloed and not useful in other parts of the site. Taking a small amount of time in advance to stay with the full CMS will save later issues.

The good news with the Crownpeak CMS is that all of the above issues are already solved.

You can use the system as a "full CMS" or take a "Headless" approach depending on the needs of each part of your content ecosystem, and they can even be used in tandem to deliver the same or related content to different systems at the same time.