Going Headless: Is it worth it?
Headless is a term thrown around a lot in the development lexicon these days, but what exactly is it and why is it getting so much attention? Well hopefully by the end of this you’ll have a good understanding of the principles of headless content and why it’s such a hot topic right now. The basics of a headless system come from the fundamentals of a Jamstack approach to digital architecture.
What is Jamstack?
All sites are served as static HTML files. And with Jamstack we serve exactly this, prebaked on the server ready to be rendered by the browser reducing client-side runtime, thus speeding up how quickly sites are displayed.
Jamstack in its simplicity brings all sorts of benefits to the sites and projects it's used on, from security through to scalability and maintenance of a project and the fundamental goal of performance.
The advantages of Headless Development
With the use of a Jamstack, there are fewer points of failure. The infrastructure we use delivers content that has been rendered server-side, as such everything we deliver to the browser can be cached or distributed via content delivery networks (CDN).
As a result of this architecture, we leverage the security of multiple systems. Our chosen providers for content delivery and content distribution network are industry leaders and as such have multiple levels of security for their platforms and large teams of cybersecurity experts.
With sites being served entirely from a CDN there is no complex logic to determine asset caching policy, we do not need to selectively cache and serve content, everything can be served from a cache.
This allows for simpler deployments and faster workflows when implementing new features or adding new content.
When hosting complexity is reduced and so are the tasks required to carry out maintenance on a system.
Due to the decoupled nature of Jamstack architecture, the content is secure on the content platform and the project code that renders the content sits separately from the content. As a result, we don’t require complicated back-end integrations and can quickly carry out changes and amendments to a platform with minimal testing.
There are no complex databases to manage only the content and how it’s rendered. We don’t have to carry out updates or patches to plug security issues, once a site is built and served it’s stable.
Performance is an important metric for SEO and as such modern platforms need to be built with performance in mind from the ground up. Page loading speeds have a huge impact on conversion and user experience.
With Jamstack architecture and content being served from a CDN, the content is readily available close to the end-user ready to be served. High performance is the result of this method without introducing expensive infrastructure costs.
As the content is decoupled it can be used anywhere, meaning we can plug content from a singular system into multiple platforms across an array of end-use cases. This includes serving content to internal closed systems, public-facing websites or even apps.
We can also host our platforms on a variety of services and have greater flexibility in moving things around.
What is a headless CMS?
Most people are familiar with the concept of a content management system (CMS). Most of these systems are coupled to the rendering of the content, however, with a headless CMS the only focus is on the arrangement of content components and pages. The headless CMS is where all content and assets are contained.
It’s basically like any other CMS except that the stuff that renders the content is not included. This means that a bespoke code needs to be written to render the content fetched from the headless CMS.
This content is delivered to a platform via an application programming interface (API). This can be distributed to any system where it is needed, such as a website, a mobile app, or even in email marketing and customer relationship management (CRM) systems.
Traditional CMS vs Headless CMS
How does a headless CMS compare to the traditional method?
Since headless CMS is a relatively new technology, it’s worth asking what this new way of building for the web is like compared to legacy CMSs.
Traditional CMS is content controlled by a backend with a frontend system to render the content coupled together. Headless is simply the former part of this traditional relationship between data and render.
Having a decoupled approach to content management and display of content centralizes the efforts of the people involved in a project. Without the unnecessary overhead of the display in the CMS a content editor can focus on their work, that being adding, amending, or deleting content. The developers working on a project can focus on clean and maintainable code for display and not worry about breaking changes to existing content editor experiences.
It’s a commonplace issue in development lifecycles that large feature changes or content component changes result in database changes, therefore the overhead of this way of working is larger than a decoupled system. There are systems designed to alleviate this problem but that adds another layer of complexity to a project. Headless removes this recipe of a problem, as we can focus on the areas we need to while end-users focus on their content. The only time the two meet is when the content is prebuilt as a static page and delivered via CDN to a user's browser or device.
Many of the legacy systems are rolling out APIs to serve content headlessly however these are usually afterthoughts on an existing platform, as such they can come with large amounts of bloat and don’t offer a system that is specifically designed to deliver content in a decoupled way.
What are the benefits of a headless CMS?
A headless CMS is a single system serving content to multiple places, supporting web or mobile channels simultaneously. As it is a system that serves content from multiple existing sources, it can be reduced in complexity. Reduced complexity results in greater project maintainability and scalability.
There are also plenty of performance benefits given that content is served via a CDN and served statically, lowering requests in a user's browser. The static content can be served locally to an end-user via a CDN which limits latency issues with requests.
Decoupled content from display layers make life easier for content editors, as they can ignore code and focus exclusively on content. This results in a much cleaner content editor experience and fewer chances of breaking changes or accidentally pressing a button that shouldn't have been pressed.
Further, rapid deployment of display layer code changes and updates to content without the need for database changes mean new features or updates can be rapidly developed.
This leads to a lower cost of development. Due to the complexity of code and hosting, we can develop systems using this approach quicker, resulting in a lower cost.
So is going headless worth it?
For us, the answer is simple, we think it is. However, this may not always be the case, you have to match the skills of your team and the needs of the project to the right technologies to be able to deliver them successfully. The future of development will probably see an increase in people switching to Jamstack, as the tools for headless content delivery continue to improve and adoption from developers continues to grow.