Article_Guide

When to use Headless WordPress (and not!)

I’ve noticed quite a bit of confusion out there as to what “Headless” is – particularly with WordPress – and when it’s the right path to embark on.

Recently we were asked to evaluate whether developing a WordPress website as a decoupled, headless instance with a custom front end would be of more value to the client, compared with following the more traditional development approach.

There are some compelling reasons for custom WordPress builds:

  • What is Headless WordPress?
  • Major considerations with going “headless”
  • When to go headless
  • When not to
  • Advantages
  • Disadvantages

What is Headless WordPress?

When you take your website headless, you’re separating the backend (admin interface) from the front end (the user interface). When they’re separated, you’re able to continue to manage and author content in WordPress, whilst freeing up your content to be available for use in other applications and formats. Content is delivered from WordPress via REST API to your React (or other framework) front end. The front end is custom built. 

  •  Purpose-built means reduced code, cleaner code which in turn means site performance.
  •  Less plugins means reduced code bloat – again performance and lowers risks of breakages in maintenance and updates.
  •  Less plugins means less maintenance, and fewer risk of vulnerabilities
  •  No need for attempting to retro-fit functionality to a templated theme (which never works well)

Traditional WordPress

 

Headless WordPress

 

Big Considerations

 

Going might sound attractive, or your agency may be pushing for it given the scalability and performance benefits. It comes with some considerations though:

  • A stand-alone app will always be required to access the content.
  • There’s a higher level of developer support and dependency
  • More costly to develop and maintain

What these point mean is as the backend of WordPress is divorced (or decoupled) from the front end, a custom-built app will always be required to access the data residing in WordPress tables. This in turn means development of that app – which will be a custom build – and the subsequent ongoing support and maintenance. It can also mean hand over to other developers can be a more difficult process.

 

When to use Headless WordPress

There are some clear criteria when it  is  beneficial to embark on a Headless build:

  • You intend (now or in the future) to have content available across multiple websites, applications and platforms at the same time. For example, a web article is deployed also to an iOS or Android app, posted to medium.com, Facebook, an intranet/ Sharepoint, out of home media/ events or IOT devices
  • You have a need to design personalised, dynamic digital experiences
  • You need to scale quickly – i.e. publish content across multiple platforms
  • You need to streamline business processes, especially with content creation

When NOT to use Headless WordPress

These points highlight when Headless WordPress is going to work against you and business objectives:

  • Your website is more static – there’s no need for testing and changing new UX and user experiences
  • You have a small content team or limited content creation resources
  • Your website does not have regular content changes and updates
  • Content is not a core aspect to business function
  • You have simple publishing needs – i.e. single content stream; with no need for publishing across multiple platforms
  • Staff need the ability to modify basic styling, format, rich media, change basics of look and feel

Major advantages of going Headless

  • “Future proofed” – provides an organisation with greater future opportunities for content dissemination in the future
  • Easier to redesign in the future without changing CMS – front end flexibility; not reliant on WordPress’s limitations
  • Optimised applications for specific purposes. Each are dedicated to their own tasks
  • More secure – exploiting the website is more difficult through the backend as it’s almost completely hidden from the public
  • Improved performance – particularly for sites with heavy traffic
  • Start small and add functionality, iterate, channels over time

Wrap Up