As a Sales Director at GraphCMS, I come across a lot of professionals who get stuck in a configuration where they combine a React(-like) library with WordPress as a headless CMS. I will explain why those professionals don’t like this set-up, but let me first go over the common pattern in the paths these organisations have followed to end up in this situation.
It starts with the front-end developers convincing their management to go headless (in short, their content is delivered as data and not as HTML), as they want independence from the back-end. The goal is to have the ability to change the front-end design and functionality of their website without re-implementing the CMS, turning the website into an in-browser app, or even a Progressive Web Application (PWA).
Management, acting as a prudent pater familias, grants some of the front-end developers’ wishes. They can play with React but they have to keep WordPress as a content repository. In a later phase, as management often promises eager front-end developers, they can look into developing the system further.
This approach has its advantages: - A large migration from the current CMS - which requires project management in an organization - isn’t needed (yet). - The content editors stay in their WordPress comfort zone (editors are way less inclined towards new solutions than their technical colleagues).
So yes, there are certainly advantages to just take out the presentation layer of your WordPress configuration but I doubt that a prudent pater familias will build a leading company in a competitive landscape. Let me enumerate the problems I hear from my prospective customers:
- Performance. REST API queries are lethargically slow. One customer spoke about page loading times of 3+ seconds due to the burden of WordPress plugins. It even takes longer when the whole WordPress core is downloaded for serving the endpoints. Hmm, I don’t think marketers are happy with the conversion rates of that web application.
- Maintenance. A lot of daily tweaking is necessary to keep the whole website running.
- Editorial experience. You need to JSON-ise all your content to make the APIs work somehow. You appease content editors in the short term, but eventually they must adapt to new content formats.
- APIs. Sometimes they get access to the desired GraphQL instead of the cumbersome REST APIs, for example via GraphiQL (GraphQL’s visual IDE) which is built into tools like Gatsby. The problem then is that your API editor works outside of your content repository which makes optimizing hard.
- Compliance. Compliance teams are wary of overusing plugins since they are developed by outside individuals or organizations they don’t know.
- Sleek. WordPress comes with an overload of options, a large majority of which remain unused. This problem is exacerbated when WordPress is your headless CMS.
- Opinionated. WordPress, with all its templates, is a very opinionated system. This doesn’t change by using WordPress as a headless system. You are still obliged to follow their logic of how to structure content.
- Hosting. Lots of human resources are wasted on the hosting of WordPress, as it is often locally installed.
- Extending. Everything is separated in plugins and technical debt easily mounts up if you aren’t building those yourself. This can be very costly.
I would advise the prudent pater familias manager not to waste time with this intermediary WordPress-as-a-Headless-stage. It creates new problems and new frustrations, which you need to solve before you can move further. You don’t want to integrate the latter half of your old caravan with your new campervan either.
