Living Headless

Setting up, making choices, and living headless...


So, about Headless CMS's…

My first two jobs involved dealing with Content Management Systems. If you haven't heard the term, CMS's are web applications that allow users to edit and manage, well... content...

My first full-time job was with the Jacksonville Business Journal and it involved designing and developing landing pages within a proprietary single container editor. I'm not sure that's the right name for it, but all I had access to was one div. That was all I could edit, design, and develop within, the frame around that one div was dictated by other people.

In my second job, I was working at GleanView, a Customer Relation Management software and one of my early tasks were setting up a blog. I decided to go ahead with what's definitely the most popular CMS in the world. Love it or hate it, WordPress is responsible for powering around 40% of the internet.

What is a Headless CMS

I'm not entirely sure where the headless term comes from but I would guess the reason we call the CMS headless is because that's where our face is, maybe?

Serving a website to a user involves a lot of things. You need a server of some sort, a domain, DNS settings, and ultimately some HTML. Through this entire process, if one had to point out what the face of the website is, I think it's rational to say the face would be the HTML; the actual website the user sees, regardless of whatever happens behind the curtains.

A Headless CMS decouples the CMS from the actual website the user sees. This website for example is hosted on Netlify, but its CMS is StoryBlok, and the link between the two is an HTTP GET request.

WordPress is a great example since it can be used both as a classic CMS or a headless one.

Classic WordPress CMS

In your classic configuration, once a WordPress website processes the request through all the PHP files from your theme and plugins, it queries its database for the post or page content that you're looking for and presents the page to the user according to what it had gotten from your theme and your plugins.

Illustration showing communication between user computer and wordpress in old-fashioned wordpress cms fashion

Headless WordPress CMS

On the other hand, headless WordPress is only concerned with one part of this whole process: querying the database for your pages and posts. The process of creating the HTML for the page is not one of the CMS's concerns. There are two main ways you can get the content for the page, with a client request or with a server-side request.

Client-Side Request

The client-side request gets its name from the fact that the user's browser is the one making the extra GET request to the CMS to capture its content. This is the easiest setup for a headless CMS since there's really no server process involved. A compiled React website is nothing but HTML, CSS, and vanilla JS. So you can host the website on a CDN and let the user's browser do all the heavy lifting.


  • Very Fast

  • Can be hosted on CDN

  • Can most likely be hosted for free

  • Easy to setup


  • Poor SEO - Since the content of the page requires javascript, search engines aren't able to see content

  • The user's browser may be unreliable, causing content to load slowly or not load at all

  • Requires a potential loading state for the website to display while it fetches its content.

Server-Side Request / Rendering

Server-side solves a lot of the hurdles inherent to client-side requests. This method relies on another piece of technology, in the case of this website, NextJS, on top of your front-end library to query your CMS (or its own cache) before the HTML page is served. While it does increase the complexity of your application, it's a great method for websites that need good SEO support.

Illutstration showing the communication between client and server on a server-side headless CMS


  • Delivers HTML on the initial request

  • Great for SEO

  • Can actually be more performant than client-side since the server connection is most likely faster than the client connection


  • Definitely more complex to start and maintain

  • Requires an active server (although Vercel and Netlify both have ways to run this in a serverless fashion)


It's clear why developers like to work with Headless CMS's. It provides a very clear separation between the code and the content, while also providing freedom to develop an application or website in whatever language one prefers. And if you ever need to drop your current website, or your current hosting and move it elsewhere, you can rebuild your entire front-end without worrying about the content at all.

How to set it all up

I will probably go into more detail in the future about how I set this blog up, but if you're interested I highly recommend these articles from a few Headless CMS platforms on how to integrate NextJS with their CMS.

Last played:

J. Cole

View Page in Github