Well, a simple search in the web nowadays and you can find thousands of tutorials about using WordPress in a headless way. As modern as it sounds, the very conception of WP goes against this approach.
Look, a system is just as good as the use we make of it. WordPress, limiting our analysis to its PHP architecture, is a heavy and complete CMS design in a procedural way. The reason is quite simple: at the same time their developers needed to think of legacy resources and extensions, all the way since the beginning, it evolved from functions and hooks to provide a comprehensive way of creating new features and functionalities.
As a result, we have a community with dozens of thousands of free plugins and themes, and many others paid extensions that can virtually transform that original blogging system in anything you want:
- Online shops
- Marketplaces
- LMS systems
- Social networks
- CRM and ERP platforms
Ok, what about the headless wordpress?
Let’s start from the beginning. Headless basically means one will be using WordPress as a backend for managing content. Meanwhile, another stack will then rely on WP’s Rest API to render the views and offer the user a frontend.
Most of the enthusiasts of WP headless talk about performance and a multichannel possibility. Maybe some of the instances running a headless wordpress solution are faster. And perhaps some of them use the WP API to serve different frontends successfully.
However, there are three huge problems about it, if we consider the way most headless instances work:
- Once we are making the block editor and visual editors in WordPress redundant, shouldn’t we look for content first CMS solutions before choosing a complete stack like WordPress?
- If we plan to use WP as backend and Node.js or any other approach for designing the frontend, that means website owners forcebly need to maintain specialists to modify or change the content.
- Finally, if we want something faster than the traditional WordPress, shouldn’t we be better by choosing a lighter CMS solutions, such as Ghost or Strapi?
Why isn’t WordPress faster?
WordPress evolved firstly from a very basic blogging platform. In those times, things were definitely simpler. Those using WordPress wanted no more than a few tools for putting up blogs and tiny websites.
In two decades, WordPress moved from a timid hosted blog to the most comprehensive CMS system of the world. You can do anything with WordPress.
Its evolution always occurred in two ways: richer web design and content resources offered users freedom to create their websites (and change them, thereafter). Also, its structure based on functions and hooks simplified complex PHP structures.
Possibly, websites built in an object-oriented way or using powerful frameworks like Laravel or Symfony are faster. However, those need specialists to provide any customization or new feature, while WP users can find plugins and extensions for basically everything they want.
And that is the very reason why WP is not the fastest CMS. If you are just looking for speed and want to put up a couple of static pages, using WP can be quite stupid.
Headless or not, you can still use the Rest API
Another topic to address is how headless enthusiasts expose their product. By the end of the day, if you opt for a headless wordpress architecture, you’d better be the programmer. If not, your company is basically signing a lifetime contract with the website developer.
Disagree? Think again: if you have a traditional WP website, you can hire any WP dev by any time. You KNOW how it’s made. In a headless approach, developers can be used any framework or stack to generate views. You simply don’t know.
And as you are completely blind, you see yourself in a situation where being a hostage is actually cheaper (although still costy).
Lastly, no matter how your WP website was initially set up, you can still rely on the Rest API. That means, in spite of your website, your WP installation can serve apps, landing pages, other websites and so on.
In other words, headless or not, the multichannel serving is always possible. Of course you’ll need a more potent server to manage more requests. Either way, you’d need it in both situations.
Seriously, when we read some of the sales copies of headless CMS solutions, we can find things like this “if your company makes an update to the way it describes a product, that update shouldn’t be copied and pasted in 20 different systems”.
Personally, I already managed synchronized WP websites able to put dozens of subsites in parallel, as well as synchronize data with external APIs, SQL Server and PostgreSQL databases and even desktop apps once.
The idea that traditional CMS systems can’t interexchange data is quite misleading and unprofessional. By the end of the day, headless wordpress is just a possibility because WP has a powerful built-in API.
When is headless smart?
Having that said, of course some cases can benefit from a headless approach. Sophisticated reactive websites, sales pages and static pages, content-first APIs.
By using a headless approach, one must assume that the development efforts will be concentrated in the frontend. The server side needs to be reliable, simple to maintain and scalable – and that makes a SaaS solution a better choice in most cases.
There are a number of SaaS headless CMS solutions. Most of them offer a way to design and build pages from a hosted backend. In other words, they offer the same as a headless developed under WP backend, without the hassle or any need to be concerned about designing custom endpoints or having a server yourself: