How to improve performance via a headless architecture

Decoupling the link between content creation and display to maximise speed and flexibility

By , Solutions architect

Decoupling the link between content creation and display to maximise speed and flexibility

The Challenge

We needed to provide users of Immediate’s digital brands with rich, personalised, interactive experiences, but our platforms were tailored towards efficiently delivering static content. Creating additional capabilities within our existing framework was a lengthy process, and our page speed performance was also suffering because of the additions. We needed to speed things up, especially with the introduction of Core Web Vitals by Google making performance a key ranking factor for search results.

The Solution

Having researched many options, we decided to re-architect our Fabric platform from a single monolithic application built around WordPress into a series of independent services following a headless architectural pattern. This was a shift, not just in terms of the technologies we use, but also our ways of working. Happily, the shift opened several exciting new opportunities.

Prior to the switch, our editorial teams used WordPress to create content; it was also the system that presented content to our users. Editorial were happy with Wordpress, but it was our biggest bottleneck in terms of performance. A single-application approach also meant that every time we made a change to our code, we had to retest a vast range of functionality, which wasn’t ideal.

Now, with a headless architecture, we only use WordPress for creating and updating our content, and not for presenting this content to users. Instead, we push that content out into a set of dedicated API services tailored for optimal performance and scale.

This decoupling of CMS from how we display content has given us the flexibility to pick the right technology for us. We already had experience of working with React, but now we could embrace JavaScript using the popular Next.js framework to server render our UI components. This gives us granular control over our UI, quickly displaying our key content to users and then seamlessly layering on more interactive elements to help us achieve our performance goals without sacrificing functionality.

A headless architecture means moving to an API-first approach so our front-end services can access the content, which started in WordPress. These API services afford us an additional benefit – flexibility. Instead of Fabric exclusively powering websites, we can now integrate with a range of different mediums, which has included native apps, Alexa voice skills and even the ability to order personalised cookbooks filled with your choice of recipes from BBC Good Food.

This modern architecture has allowed us to significantly increase the level of automated testing, including unit test coverage, Postman API testing and a range of performance tests. We can also frequently release new improvements without having to retest every single feature. Our services are all containerised, capable of independently scaling up to handle spikes in demand without slowing down our site performance.

The Impact

Moving to a services-led architecture with WordPress as a headless CMS has delivered on our goals – we can now build out new features efficiently, while delivering a performant user experience.

Following the switch, we have seen significant improvements to key performance metrics, including Time to First Byte, Largest Contentful Paint, Time to Interactive and Cumulative Layout Shift – all crucial in helping us achieve our Core Web Vitals targets.

We have continued to roll out this architecture to more aspects of our platform – including our hugely popular TV listings grid and streaming hub on Radio Times – and we are constantly improving upon our performance and automation, making it faster and easier for editors to create content and see it published across the platform.

Work with us

Fancy joining our growing team?

Get in touch

Throw us a line