What is a "headless" website? | Den Creative
Headless development



What is a “headless” website?

Senior Developer at Den, Richard, looks at what a ‘headless’ website is and why you might (or might not) want one. Over the last few years there has been an increasing amount of interest in headless development and most CMS and e-commerce systems have a headless option.

Time taken to read blog post

3 mins

What is headless and what makes it so interesting? Systems like WordPress and Shopify are monolithic – they are self-contained. The backend is tightly coupled with the front end and to build a site with them means you have to work within the parameters and limitations baked into that system.

If you want to build a site with those systems you have to know the platform.

A headless system however, doesn’t have the same limitations. The back end makes its content available through a set of APIs which a front end can be built around.

The head is the presentation layer – be that a website, app or some other service and the body is where your content is managed. That could even be multiple places, you might have a headless Content Management System (CMS) for your blog posts and a headless ecommerce system that powers a shop on the same site.

In fact there is nothing to stop you blending content from several sources into a single product page – you can choose from the best tools to meet your specific needs.

The same content can then be used across multiple presentation layers – that could be multiple layouts, devices, channels, and applications.

The benefits of going headless

Separation of concerns – being able to develop a front end separately from the back end generally means a quicker turnaround, especially when mock APIs (mock data responses to requests from the front end) can be used while the back end is being put together. Teams can work in parallel or can focus in on specifics without having to wait for milestones to be reached.

Developer experience and resourcing – a front end team can build a site or app without ever knowing or caring what the backend is. They don’t need to be WordPress specialists or understand Shopify to build a site, they just need to know what the APIs are. This means they can work across whatever project needs them.

Flexibility – content might only be used on a website to begin with but if that ever changes all that’s needed is a new presentation layer – the content will be adaptable to wherever it’s needed.

Scaling and infrastructure – a monolithic application will usually require one or more servers and resources which are hard to scale. You’ll either end up paying for resources you don’t need or find you don’t have enough when a spike in traffic comes. With headless it’s much easier to design a solution that can scale up and down automatically.

The drawbacks

Headless isn’t the perfect fit for all scenarios and isn’t suitable for every project.

Costs can become complex and unpredictable. You could end up using several systems, each with its own cloud-based services and most of which will have individual costs attached. If you’re paying for computational resources based on usage and you see a huge spike, you can expect to be billed accordingly – which can sometimes be a nasty surprise.

Systems like WordPress, Shopify and Magento will have a rich and powerful ecosystem of plugins that can quickly bring complex functionality to a site. Headless requires you to build from the ground up and even with components that can be used across projects, you’ll usually need to build them yourself from scratch.

Many would argue that this is a benefit rather than a drawback but perhaps not by clients who have a limited budget or timeline or who want a proof of concept.

The right tool for the job

Headless is a great option if the website or app you’re building would be restricted by a monolithic system or if it’s likely that the content will need to be used across several channels. It’s also a good option for sites that are likely to need infrastructure that can scale quickly.

If you’re creating something which is likely to remain fairly static and doesn’t require a multi-channel approach then traditional systems are still a very good choice.

If you’d like to find out more about our capabilities and what we can do for you, or you’d like to join our team, get in touch.

Headshot of Richard Starr.

Richard Starr

Senior Full Stack Developer

Created with Sketch.

Meet the Team - Naing Min Oo

Created with Sketch.

Meet the team - Rob Swallow