An Introduction to Headless WordPress
A look at the basics of Headless WordPress and how and why you would decouple the WordPress back-end from its front-end.
Oops! We could not locate your form.
A look at the basics of Headless WordPress and how and why you would decouple the WordPress back-end from its front-end.
WordPress is an incredibly powerful and flexible CMS platform providing excellent backend and frontend management. As it manages both frontend and backend it is known as a monolithic or coupled CMS.
This means that it is excellent for beginners, but also super customisable and scalable for creating custom enterprise level solutions.
Custom theme development can achieve almost anything from front end design. With WordPress creating its performance team and continually evolving the platform, performance and speed are becoming less of a concern too.
But there are still a few reasons certain businesses may choose to go the headless route.
As the name suggests, it’s WordPress without its head, which is its front-end. No guillotines required.
Some businesses or web developers opt to use WordPress’s ever-popular backend but want to decouple it from its front end. Instead, the front end is handled by something else, like React, Vue, Angular, or a static site generator like Gatsby.
WordPress will cease to have any control over how the front end displays the content pulled from it.
The developer’s preference and the website requirements will dictate what technology is used for the front end.
For example, for a website that is likely to be updated very regularly, you probably wouldn’t want to use a static site generator.
If you want to create a progressive web app and a mobile app which share the same information, you would choose a technology best suited to that.
The front end and backend are linked via API which makes the resources required from the backend (posts, users or taxonomies, etc) available to the front end to be displayed. The WordPress backend has the data, whilst the front end dictates how the website will display that to users.
Going the headless route comes with advantages and disadvantages. Its use should be fully explored before deciding to implement, to ensure it is suitable for the organisation considering it. It can often come with more cost in development time upfront due to complexity, so use cases should really drive decisions.
The major reason people choose headless is that you are effectively cutting out the middleman. Removing the front end of WordPress means you no longer have to load all of the additional scripts and styling needed for it to function correctly. Your front end website can be lightweight, whilst the API fetches the data to display. This brings obvious performance and speed improvements.
The other major advantage of headless is that it’s great for organisations that need to quickly deploy their content across multiple channels or platforms. For example, they could have a website, a progressive web app, and a mobile app all built on top of WordPress. So when changes are made in the backend they can be output across these various platforms at once.
Alongside this, headless allows a developer to use whichever front end technology they like working with. Whilst marketing teams who will use the website day-to-day can still use a backend they are familiar with to add, manage and edit content.
Whilst headless can be a great solution for the right project, it isn’t suitable for every website. It comes with disadvantages too, which can make or break whether it is a good choice.
First off, you lose access to the entire WordPress ecosystem. Any plugins you have on your existing site that control something on the front end will no longer work, and no more easy string translations.
You won’t be able to use popular plugins like Gravity Forms or ACF in the same way. Instead, you’ll need to create a way to support these things on the decoupled front end.
Another big turn off for people, is that you lose the easy WYSIWYG editing experience. It can be difficult to see how your content will look, with no simple preview available.
Another issue is that a headless setup isn’t very portable, and would rely on the developer to manage. It’s pretty locked down, so moving to a new developer or support agency would be trickier. It also wouldn’t be easy for a business to manage internally.
It’s also not ideal for quick and regular changes. You can’t install plugins in the normal way and get on with it. Nor quickly create a new custom post type or add a new section to your website. Additional development will be needed on the front end side to accommodate new additions.
As you essentially have 2 separate websites, you’ll also need 2 domains, or 1 with a subdomain. Then hosting for both. This is an extra cost to consider.
Headless has ebbed and flowed in popularity over recent years. Some people love it, some people hate it. It certainly isn’t the right solution for every site, but can be viable and reliable for the right project. It can definitely bring improvements to the speed and general performance of a site for businesses looking to eek out every millisecond.
It’s a less suitable option for websites that require complex integration and functionality in a workflow. Standard WordPress custom development is more advisable in these cases.
Headless is something that should be approached on a case by case basis. With full disclosure of pros, cons, costs involved and impact on future development. Then an informed, fully educated decision can be made by a business, as to whether it’s the right solution for them.
WordPress Core version 6.5 was released on April 2nd. So let's take a quick look at some of the main changes it brings with it.
WordPress Core version 6.4 is released today. So let's take a quick look at some of the main changes it brings with it.
If you're looking for the right contact form solution for your WordPress or WooCommerce website, there are certainly no shortage of options on the market.