Elixirr Digital

WordPress has come a long way since its inception in 2003 and people always seem to find new and interesting ways to use it. By design, the extensive customisations made possible by plugins have changed the way developers create websites and extend functionality for clients.

However, it seems that more recently (although I may be a little behind the curve) there has been a spike in the popularity of the ‘headless CMS’ or ‘decoupled CMS’. I wanted to explore this concept and consider how it could benefit us as an industry.

What is ‘headless’?

Before we dive into a meaty discussion, it’s important to know what headless is and what it’s not. Headless WordPress is not a new CMS, system or coding language. Headless WordPress is a term to describe the back-end of WordPress (the admin dashboard) being separate from the front-end (the website you see in front of you).

Now, you may think they’re sort of separate anyway, but they’re not. WordPress’ infrastructure links the two together and they very much go hand in hand, as you’d expect. However, a headless website tips this concept on its head (pardon the pun). For example, you could have a basic website built using only HTML, CSS and JavaScript which pings the WordPress REST API instead. The REST API (Representational State Transfer, Application Programming Interface) is part of the WordPress dashboard and this could be hosted elsewhere and not on the same server as the actual website your visitors see. This means that you can access the website data (such as your pages) from an external system easily.

Wait, what’s an API?

API stands for Application Programming Interface and it essentially allows one website talk to another and request data. APIs are at the heart of all headless systems, not just headless WordPress systems. It’s like how apps on smartphones function; by calling external APIs to fetch the data they need for whatever the app is doing. Headless WordPress is doing exactly that; calling an API to fetch posts, users or taxonomies and then showing them on a page.

The Advantages

The main advantage of ‘going headless’ is that you cut out the middle-man (in this case, WordPress) from having to load all kinds of scripts, styling and support for browsers to function correctly. It means you only need to build a front-end website consisting of lightweight pages which use the WordPress API to fetch and display the data to the user.

This makes the development of the website much faster and simpler, which ultimately saves a lot of time. It should also speed up the website itself, as you don’t need to include all the default bits and pieces usually present every time the page loads. To put it simply, you get the WordPress experience without the WordPress interface and all of it’s quirks.

The Disadvantages

There are a few disadvantages which, to some, might be a deal breaker. To start with, you can no longer login to WordPress and edit the website in the same way. You’ll still have the dashboard to log into somewhere, but you won’t have the classic WordPress Toolbar with quick links to your favourite administrative pages.

On top of that, any plugins you have installed on your site that change or do something on the front-end won’t work anymore. As you’ve removed the link between the front and back ends of WordPress, you can’t use things like Advanced Custom Fields or Gravity Forms (two very popular WordPress plugins) in the same way and would need to create a way to support these things on the front-end of the site.

The Future

To my mind, the advantages of a headless website significantly outweigh the disadvantages. The headless route has proven to be both viable and reliable, particularly when considering the improvement of speed, quality, and general performance of a site.

That said, it’s not necessarily right for every site – it wouldn’t always be the most viable option in scenarios that require deep integration and functionality throughout a workflow. In those instances, it’s probably best to stick to standard way of WordPress development. Judging the use of headless on a case by case basis is the wisest move but should be something to consider when planning future projects going forward.

What do you think? Is a Headless WordPress solution something that would work well for you? If so, why would it be better than the traditional way of WordPress development? This interesting topic is one that that will surely increase in popularity over the coming years.

More on this subject