Why we love headless content management

Since the dot com boom, when we said things like ‘webmaster’ and ‘e-mail’ with a hyphen, developers have been working on ways to manage web content efficiently. It’s in everyone’s interest; designers, content managers, and most important of all, users. In an industry that is constantly evolving with new platforms, standards and trends, it can be hard to keep up.

We’ve seen the content management (CMS) landscape change a lot over the last few years, with headless CMSs in particular affecting the way we approach content in many of our new projects. I’ve worked on countless CMS projects over the last 15+ years, so I thought I’d take you on a magical journey and delve into the past and present.


I like to go glasses-less when I work with headless.


A brief history of web content management

The very first CMSs emerged to the market around the late 90s out of a need to serve websites with more dynamic and engaging content, and to be able to do so in an organised and efficient way. Before this, websites comprised of static HTML pages that were uploaded to a web server using an FTP program. Managing an entire website in this way was inefficient and often prone to error, as uploading and maintaining content was time-consuming, and it was too easy for the files to be accidentally overwritten or duplicated on the server. I dread to think about all those hours I lost before version control was a thing.

Fortunately by the early 2000s, CMSs were becoming commonplace. Open source software was gaining popularity, and this helped to drive the development of various free platforms like Drupal, Joomla and WordPress. These initial CMSs solved a lot of issues, as not only did they allow content to be organised efficiently and securely, they also offered the ability for anyone to modify the content with relative ease. This completely removed the need for a developer to be involved in the day-to-day content management on a website, as it was no longer a requirement to have an understanding of HTML, CSS or any programming languages at all. 

Although these types of content management systems are still commonly used, they aren't without their faults.



Monoliths have problems too, you know

These types of content management systems are described as monolithic, as they are a single-tiered application. The back-end and front-end are coupled together, only allowing content that resides in the back-end to be delivered to its front-end. 

This means that every time a visitor views a website in their browser, the application has to generate and then deliver HTML for each page request. This can significantly affect page load time, depending on the size and content of the page. Performance plays a significant role in the success of any website, and it doesn't matter how good your design or offering is if nobody waits around to see it. In general, monolithic applications rarely offer superior performance.

Monolithic applications are also very particular about how the front-end is built on top of them. Often, the freedom to design the exact experiences we want for users on a monolithic platform has to be compromised in some way because of its structure, affecting the workflow and ability to choose the best tools for the project. 

Security can be an issue too. According to the WordCamp Central website, there are currently over 75 million websites based on WordPress. This makes it the most popular content management system, and as a result, a prime target for hackers. Statistics from 40,000+ WordPress websites show more than 70% of installations are vulnerable to malicious attacks.


Our Creative Director, Pete, working with InVision.


A welcome (r)evolution

Web technologies were forced to evolve following the release of the iPhone in 2007, which brought with it a massive surge in mobile traffic. Websites were no longer just being served on a desktop or laptop screen – they had to serve content to a whole range of screen sizes, particularly as a variety of Android smartphones came to market. On top of that, mobile users were starting to expect websites to look good and offer a sleek user experience.

The arrival of responsive web design in 2010 solved some of the problems, as we could deliver the same website to mobile and desktop screen sizes, but what about everything else? These days we can consume content from televisions, games consoles, watches, cars and even some kitchen appliances have built-in apps. All these new and different channels meant that serving content from your trusty old monolithic website was not necessarily the best option.

Off with its head

A bold solution to this was to separate the front and back-end of a CMS. Think of the presentation layer or front-end as the ‘head’ of a CMS, and the back-end content repository as the ‘body’. When we separate the two, the content repository then becomes headless. What makes a headless CMS more flexible than a monolithic CMS is its content-first approach. The headless CMS is a central content store which can be used alongside multiple applications. And by using APIs to access the content, it can be delivered to several different channels, whether it's a desktop browser, a phone, wearable or your fancy fridge.

Performance and scalability really matter, and by using a headless CMS we’re not bound to the constraints of a traditional CMS. Instead, we have the flexibility to choose a scalable and fast performing front-end that works best for our project. The preferred choice for many of our headless projects is Next.js, as it meets our requirements for a brilliant front-end framework. You can read more about Next.js in this blog from Kyan’s Dave Quilter.

The many heads of headless

Now that we have an understanding of what they are, let's take a look at some of Kyan's favourite headless CMSs. Despite headless only being around since 2017, the market is already reaching saturation, but we’ve settled on a favourite few and have been able to apply these to a number of Kyan client and internal projects.



  • Kentico Kontent
    We are a Kentico Kontent Platinum Partner, one of just a few in the UK and Europe. It’s a brilliant platform and one that we’ve been able to use in our work with Electro Rent – an expansive site offering the lease and hire of test equipment. To learn more about Kentico Kontent, why we favour it, and what it's like to switch from a regular CMS, check out our Head of Technology’s recent talk.

  • Contentful
    Contentful is an alternative headless solution, with an API-first approach and great speed optimisation. We’ve used Contentful in our work with LW Theatres – a project where content and distribution is key to customer conversions on a wide variety of devices.

  • Netlify CMS
    We used Netlify on our internal Kyan Handbook – a central, content-rich repository for staff members to find useful information. Built on React, and with great GitHub integration, it was a no-brainer for us.

  • Sanity
    Whilst we’ve yet to use Sanity in production, we’re hoping the right project comes along soon. It’s rich feature list, including complete customisation with competitive pricing, make it a very attractive offering.

Choose what's right for your project

Not every technology is a great fit for every project. If it’s not obvious yet, we are big fans of headless. But a more traditional approach to content management may be suitable for your project – perhaps for a portfolio website or something relatively simple. With content clearly now king, and performance being a primary requirement, headless content management suits the modern web and will make the lives of writers and content managers a hell of a lot easier with the flexibility that it offers.

It’s worth taking the time to look at the different headless options out there and seeing which is right for you. If you have a project in mind where content is key, then get in touch. We’d love to chat about it.

We are Kyan, a technology agency powered by people.


Previously from our tech team:

Building our own office Jukebox using Mopidy, NodeJS and React by Duncan Robertson
Why do we love Next.js so much? by Dave Quilter
Things I wish I’d known before I started with React Native by Carmen Lopez Guerra
How Ruby if statements can help you write better code by Dave Cocks