A headless CMS overview

I got a question from a prospect the other day. They wanted to know how a Headless CMS will help them change and evolve their website faster and -hopefully- without our intervention. Instead of answering their email right away, I asked if I could deliver my answer in a blog post because I think this topic may be interesting to others.

Gabriel Chertok avatar
Mar 12, 2021
Fayorit typewriterPhoto by Florian Klauer on Unsplash
A Joomla screen

First, I think it's important to understand what clients have in mind when you say you will use a CMS.

If you are an old person like me, you probably remember this image. It turns out that for 2010 this was cutting-edge technology.

I think a lot of clients also have this picture in mind. A stiff website that throws crappy results, and that's probably going to break with the next update.

But this is not the case anymore. It's 2021, and we have better tools that can have the best of both worlds. Writers can enjoy a clean UI without distractions. Marketing people can create pages on the fly without the need for a developer, and developers can create great websites without the CMS messing around with their HTML.

What we use today

At Ingenious, we use Prismic. It's the headless CMS that powers this blog, but this should apply to any headless CMS out there. The headless part refers to how the content is de-coupled from the website that shows it.

Decoupled CMS architecture

A headless CMS typically exposes a web application where you can define taxonomies, or how Prismic calls it, content types. These types can be composed together to create complex behaviors such as posts with authors, authors with social media links, etc.

While this sounds great, headless CMSs need custom coding. It requires a custom website that consumes the content we are shaping on the other end of the tunnel. We cannot just throw a template and move on, and for a good reason, that technique generates poor results.

The communication is usually done via a JSON API or a GraphQL interface. For this blog, we chose GraphQL. It's nice because, in the frontend, you can query for the specific fields you need, not the whole document.

Project generation

Typically, CMS-backed websites are relatively static. Once you create a landing page or an article, that's pretty much it. You may want to come back to edit or revisit the content, but the write/read ratio is 1/100. Your content will be consumed much more than it's going to be updated.

That's why headless CMSs play nice with the concept of Static Site Generation. SSG is a technique that favors pre compilation of the site over constantly accessing a DB for the contents. The resulting HTML files are distributed and served from a CDN.

To achieve this, Prismic -and many other similar tools- allow you to call a webhook when new content gets published so your CI/CD can kick off the compilation process.

Going dynamic

So far, all the content we create on the CMS is static; this means you cannot mix and match components inside pages. Imagine a page that may -or may not- have a callout, a testimonial, a Twitter quote, etc.

On Prismic, these dynamic parts of a document are called slices. Slices are defined in the component type, same as regular fields, but those won't be presented to the user as a must-fill. They are optional and repeatable, users may create as many slices as they want for a given document.

Slices in action


In summary, if you need better results from your CMS and can afford the time and money it takes to create a custom website that pulls data from these tools, I recommend making the switch.

Not only do you get more fine-grained control over the presentation, but also your team benefits from the freedom of focusing on what they want to accomplish, not cheating the tool to do what they need.