When is Headless the Right Solution: A Guide to Going Headless

If you’ve looked into building or upgrading a website in the last few years, you may have heard about “headless” content management systems (CMS). The term gets thrown around a lot without a lot of meaning behind it, to the point that a lot of folks feel like they must build on a headless system at this point, even if they’re not really sure what that means.

A “headless” system is one where the software (either a single source or multiple sources) that maintains your site’s content and the software that displays your website to users can operate independently of each other.

We say “independently,” but how independently depends on the software. Some solutions are designed to build a completely static website, so the site will work normally even if the CMS isn’t running. Others will use active calls back to the CMS to get information while users are browsing. Both of these types of solutions would be marketed as headless.

Is headless the future? Is a “connected” CMS still the flag bearer? It all depends on the site itself: let’s take a look at the advantages and disadvantages.

The advantages of going headless.

There are a number of advantages to building a headless solution, but the most common are improved performance, increases options, and the ability to “COPE” (create once; publish everywhere).

First, headless solutions can improve speed and performance. Traditional “full stack” content management systems, like Wordpress, build a page as a user requests it. On the other hand, most headless solutions “build” the website as simple static files when the content is published. These will load quickly since the server doesn’t need to think. And, because files are not contained to a single location, they can be spread out globally in CDN caches to speed things up.

Another advantage is choice - because the CMS only provides the content, you can build the website on almost anything. If your team would prefer to use a javascript framework like React, it’s easier to implement it with API calls to the CMS rather than using a templating system. 

Finally, an often-stated benefit of using headless is support of multiple ‘heads’. Content can be delivered to your website, your mobile app, and a print workflow all at once — as long as your content is designed to support this.

(We’ve seen teams select a headless option, then build the content so that it only works on the website. In designing a content model — the fields you fill in your CMS to build your site — so that it’s focused on the website, teams are actually negating this advantage. Think about it this way: if articles have a “sidebar” field for the website, but no sidebar in the app, where will that content go?)

The disadvantages of going headless.

There are, of course, disadvantages as well — the biggest one being an increase in complexity.

With all of the promise of choice and multi-channel publishing, the downside is that a team going headless has to make those choices. For example, with a traditional “connected” full-stack CMS, one system is handling the content editing and delivering the page through templates. These systems are designed to work together, and features like personalization, A/B testing, page previews, and other features focused on making your work easy are all built in.

All of these things can be done in a headless system, but you’re going to need to select them separately and figure out how to make them work together. And because there are so many different platforms that can work together, your solution won’t be like anyone else’s, which means you’ll need to own more of the maintenance and support.

For example, let’s look at something we often take for granted: editor previews. With a connected CMS, users can often quickly view how the page will look to users — and in some systems, even make direct edits on the user-facing page. Headless systems, on the other hand, often rely on a system that requires a site build before publishing. When the solution is built, the editor experience needs to be addressed while integrating the delivery system (the “head”). Otherwise it’s not uncommon to have to wait a few minutes before seeing your content go live.

Choosing headless — is it right for you?

So how do you decide on the right approach?

First, keep your options open.

Even if you don’t need a headless solution today, selecting a CMS that can do both makes sense. There are a lot of systems that allow you to build a normal templated site now and still provide a good API for going headless later.

Look for systems that provide a GraphQL API. GraphQL is a content API that allows a lot of flexibility in how to access CMS content. Many of the tools used to build headless sites and apps already support GraphQL.

Go headless if your situation requires it.

If you have an immediate need for a headless solution, plan on it from the start. Typical situations that might point you towards a headless build would be: 

• Needing to provide content to lots of different channels. If you need to feed content to a site, an app, an intranet, and several other systems with different designs, headless might start to look attractive, particularly if those systems are controlled by different teams. 
• Needing to integrate with or build a particularly complex site. If your team is building a single-page-application (SPA) type site, where the site itself is more like an app, you might find yourself limited by a normal template model, so a complex headless build might be the right answer.

Build with a connected approach where it makes sense.

If you don’t have a scenario that requires a headless solution, you may benefit from the advantages of a connected CMS approach. 

There are obvious benefits to using the same system to both manage the content and deliver the site. Remember that a headless solution will require custom solutions to features that are simply table stakes for a connected CMS.

Know what you need, not what you’re being sold.

Because it’s a buzzword, a lot of sales teams will lean in to selling a headless solution. If that’s what you need, great! But understand that you’re usually buying into a more complex solution. If you’re making a bigger investment up front, make sure you understand why, and how that investment will pay off down the road.