WordPress is a large monolithic content management system (CMS). It allows users to create and manage pages, posts, images, videos and more digital content that is displayed on the web based on a constructed theme or layout. Allowing for someone with little to no development knowledge to create simple web sites with a few clicks. If you are a developer, WordPress is powerful because it gives you access to an admin environment to manage all sorts of content, but the front-end experience can be lacking and often times bloated. Wouldn’t it be great if there was a solution that allowed for a developer to utilize this already well maintained and developed admin interface but gave the freedom of creating a complex front-end experience that many web applications have today? This is where a “Headless CMS” approach comes into play.
Headless still gives the user all the same power they had before with a traditional WordPress approach. You can still manage content, upload images, videos and more, but now you can access that information at anytime from anywhere.
Benefits of Headless
There are many benefits outside of developing in your preferred language when making the leap to headless. First off you no longer have to worry about security vulnerabilities that inherently exist with a traditional WordPress setup. You can throw your WordPress installation on a private server that the end user doesn’t access and hit the API from a completely separate whitelisted server that hosts your web application. This cuts down on many of the usual vulnerabilities including, brute force attacks, file inclusion exploits, SQL injections, cross-site scripting and malware.
Along with the increased security that a headless solution provides, you also gain a ton of scalability. With newer projects like React you can manage smaller front-end builds, static site generation and overall a lighter design infrastructure than the bloated front-end that exists with WordPress. For a rich user experience, we often lean on site generators like Elementor to create our WordPress front-end. However, over time these tools have become so massively large and resource heavy they cause large performance issues on load. We have observed desktop and mobile performance scores on Google’s lighthouse scoring system decrease recently as these plugins update.
Finally, one of the large selling points of headless is developer experience. It’s easier to create and manage a continuous pipeline and git flow when working with a traditional web application. This allows you to keep the front-end managed easily and at most you merge databases between a testing and production environment for WordPress using something like WP Engine.
Why not go Headless?
There are certain times where headless may not be the answer. The most obvious reason we would not choose headless as a solution is if the end goal is to hand the project off to a non-technical user who plans to add content and change layouts over time. This is where WordPress shines on its own as that is its intended use. If you are weary of managing twice the resources, headless is not the right solution. Going headless means double everything servers, resources and more. You must split a web server out and a hosted instance of WordPress – that can be daunting and sometimes more complex than is needed. Headless also means the potential for more maintenance. WordPress has a diverse library of plugins that often help with basic web site features that are necessary for a functioning visible site. However, when decoupled you lose a lot of popular plugin support. While some popular plugins have shifted support over to headless on top of their normal function this is a slow shift but does look promising for the future of Headless WordPress as a widely useful tool.
Ultimately, the decision for going headless is up to the developer and the needs of the project. If you want the ability to scale without performance restrictions but need the ability to manage content in an already created and standard way – Headless WordPress is a great option.