Back to learn
Development
How to deliver flexibility, speed and consistency with a headless CMS
by Henry Kirkness - 16/5/2022 - 4 Min Read

When it comes to contentious topics in the product space, content management systems (CMS) get their fair share of air time.

I’ve heard many people argue that they’re pointless without regular updates. And considering the time it takes to create editable fields, teach clients where to find those fields, what data to expect and how to change it into a usable format, I can appreciate why hard coding might seem the smarter, more efficient choice.

But with the ever-growing demand for businesses to pump out fresh content, it’s easy to see why more and more of them are crying out for a CMS. And whilst there are some great off-the-shelf products, understandably they have strict themes and lots of limitations. They can also bring challenges around speed, customisation and consistency. Challenges we worked to overcome with a headless CMS and revolutionary approach for co-working space provider Runway East.

The need for speed

When you’re building a website or app, you’ve probably found yourself wanting the flexibility of hard coding with the functionality of a CMS. Especially if your brand requires custom elements and regular updates. The trouble is that merging hardcoding with a CMS can really slow down the design and build.

For Runway East, we needed to come up with a smart solution. How could we make a CMS really work?

To deliver both customisation and control for Runway East, we switched focus from hardcoding 20+ pages (and making some fields editable) to creating a series of customisable components that could be used to produce an infinite number of pages. In this way, a page became just another component of the CMS. And by mapping these customisable components to a React component in the code base, we were able to make both composition and development effortless.

Concentrating on customisable components not only expedited the build but also significantly reduced the QA burden, giving us extra time to spend on the finer detail. Better still, it allowed us to move the design phase post-build, meaning we could see the ‘live’ layouts and iterate quickly.

Total control

When you’re hard coding a site, it’s easy to get all stakeholders aligned on the look and feel during the design phase. Whether that's the ideal copy length or the preferred padding of a page. But add in a CMS and all of a sudden the SEO person has written War and Peace in the ‘About Us’ section a month after launch.

Given Runway East had just spent a shed load of time and money on a rebrand, having a site that adhered to the new guidelines was a huge priority. By creating bespoke components, we were able to dictate the look and feel of not only the pages at launch but all the pages to follow. We did this by stress testing each and every component to ensure that no matter what order or combination of components existed, the finished page would always be on-brand. We also built in the option to limit things like character count (sorry, SEO friend), removing another barrier of many off-the-shelf CMS-s.

The memory game

One huge benefit of hardcoding is page load speed because your site isn’t busy trying to locate content before loading it. Add in an off-the-shelf CMS, and suddenly you’re dealing with a potentially infinite amount of content hosted remotely.

When building out Runway East’s site, we needed a way to accommodate loads of content living in a CMS without compromising site speed. The solution? Incremental static rendering.

Incremental static rendering works a bit like setting a website refresh reminder. Every time a user visits a page on your website, it’s automatically triggered to look for new content in the CMS. If new content is detected, the page will be regenerated in the cloud, ready for the next visitor. This process is super quick, given page regeneration is not limited to user requests and means your next user doesn’t have to wait for the CMS API to return the page data. Magic.

Full transparency: incremental static rendering does mean some users will receive "stale" content whilst the page is regenerating, but it’s a small price to pay for site speed overall.

Of course, for some businesses, an off-the-shelf CMS such as Squarespace or Wix will do the job nicely. But for those with custom elements also looking to maintain consistency and speed, a bespoke approach is the way forward. And as Runway East’s site proves, by switching focus to the jigsaw pieces instead of the overall puzzle, it is possible to deliver the customisation of coding with the control of a CMS.

NB: we used Dato’s CMS to build out our components, which we loved. It’s super flexible, fast, and really easy to integrate. We love Dato so much we’re one of their partners.

I'm the techy-co-founder at Planes. I love working with our developers and clients to solve technical challenges, whether that's through hands-on coding or coaching and support.
Henry
 
Kirkness
henry@planes.agency
Copied to clipboard!
We think you might like
Get more fresh ideas like this in your inbox
Get more fresh ideas like this in your inbox
Let's shake things up
Pages loaded on average in 1.0s, emitting ~0.46g of CO2.
Pages loaded on average in 1.0s, emitting ~0.46g of CO2.