What it is ‘Headless WordPress’? Is it something your WordPress based website needs? Is it something you should consider for a new project? Here is an explanation, why this is of significance and whether or not it might be important for your site.
In order to understand why ‘Headless WordPress’ we need to understand what problem it is solving, that gets a bit technical and its roots lie back in the beginnings of the internet.
The limits of PHP and HTML
HTML is not dynamic, it was never designed to be. To change the content requires a new html page to load. With simple text based sites of the early internet this was not a huge problem. As sites got graphically more complcated this entailed entering a lot of repeated code in each file. This became difficult to maintain for large graphically complex sites.
Languages like PHP and the use of a database helped with the repetition of code and to separate your content from your html. It reduced the workload and made things easier to maintain. However it still worked within the limits of a page load. For the web borwser to display new content a page load was always needed.
This was especially important for companies where scalability, performance and ease of deployment were priorities like the developing Social Media websites. Social Media and other companies and individuals were facing these issues but on a massive scale. They couldn’t implement solutions that were appropriate for a smaller websites, they were not scaleable or easily maintained at that scale.
A better WordPress?
Ideally we’d want the mature user friendly WordPress editing environment and database combined with the efficient, dynamic and scalable front end of one of these frameworks/architectures. This wasn’t easily done as WordPress had a very set way of working and accessing the database.
In 2013 a WordPress REST API project was unveiled that exposed the data of a WordPress website via the commonly used REST architecture using a plugin. This changed everything. Now there was an easy way to match these architectures/frmaeworks with the data in a WordPress site while retaining the user interface. In 2015 the REST API became core to WordPress.
This feature allowed web developers to access the data held in a WordPress website which is unopinionated on the environment within which that data is used.
With this approach you can retain the investment in WordPress, the familiar and famed easy to use editing of WordPress and combine it with a performant and scalable ‘app like’ front end.
Typically however implementation was still difficult in those early days, almost everything had to be either built from scratch in the architecture/framework you were using or involved configuring modules to work to work with it. There were still many problems to overcome and many developers created their own solutions independently.
Only sites that had the resources to support such development used it. It was too costly for the average WordPress to develop and maintain.
Since then purpose built solutions, many inspired by the experiences of those pioneers, is now bringing Headless WordPress solutions into greater viability. It is now much easier to develop and deploy Headless WordPress. There are two main solutions that have reached a level of maturity that almost any developer can implement them.
Gatsby.js and Frontity React Framework. Both of these are Open Source projects and are free to use.
Gatsby vs Frontity
Gatsby and Frontity create a dynamic front end for WordPress usually served from a separate serverless or node.js based environment but retaining the WordPress back end, they are both frameworks built in React.js.
Gatsby is more of a generic solution for any website, which also has a WordPress specific solution supplied for WordPress. It has been around for longer than Frontity. The downside is it still takes a fair degree of configuration to setup and to solve all the WordPress specific problems that need to be resolved. It is mature however and is in greater general use.
With Frontity most of the core problems with integrating WordPress with a dynamic library/framework have already been solved for you, and there are multiple downloadable modules to extend that. Frontity has been designed and written to be similar to WordPress so some of the concepts used within it are based on the way WordPress works. Someone who has only started to learn React.js will greatly appreciate this, it just makes the job easier.
The other upside for Frontity is ease of deployment, the Frontity team have been cognisant of the complexity of deployment for these kinds of architectures and have made it as simple as possible.
However a downside is it has a smaller user base and therefore a smaller support base.
Good news on that score is Automatic, the makers and maintainers of WordPress.com and the WooCommerce plugin, have invested in Frontity as they see its great potential so this situation is likely to change.
Overall I prefer Frontity. Its more understandable to me, I already have some React.js knowledge but more crucially for me Frontity is aligned more closely with WordPress, my core speciality. The deployment and setup are also easier. This made the choice a no-brainer.
Who should use Headless WordPress?
Your instinct might be ‘everyone surely’ and to a degree I’d concur. In practice a Headless WordPress setup is almost certainly going to be more costly in most circumstances than a regular WordPress to setup and maintain.
There are also some technical difficulties. Not all WordPress plugins are supported in Frontity and Gatsby. If the Plugin does not expose its data or function in the REST API, then it’s not usable at all without some extra effort.
If the data is exposed and there is a module that supports that Plugin in Gatsby or Frontity you are fine.
If there isn’t then you are on your own having to build custom support for that plugin. At the moment there is precious little support for more than a hand full of plugins. Developing a Frontity or Gatsby based front end with you a site with a lot of plugins is going to be expensive.
So it becomes a cost/value analysis.
Who will beneift from the extra costs and development needed to create, run and maintain a Headless WordPress site?
At the moment high traffic sites that gain their equity from serving a large quantity of users and sites that can benefit from the speed increases or working more like an application than a website are the main kinds of WordPress based sites that will benefit the most from Headless WordPress.
Nothing stays static however. Search engines, new standards and user expectations are continuing to drive changes in website design, standards and architecture.
In the long run all website could need to be dynamic and ‘app like’ in their responsiveness because users and search engines expect and demand it. About 40% of the internet is hosted on WordPress. In which case running Headless WordPress with something like Gatsby or Frontity could become the norm rather than the exception.