Headless WordPress - What is it and why should I care?

I have been building websites since 1999. Back then it was only HTML files with inline CSS and a touch of javascript. For the past 12 years I have been using WordPress. This added a database, PHP, and a world of plugins and themes for extra functionality and display.

The problem is things are getting slow. Things are getting complicated. What if we could go back to simplier times? After all, the browser is a simple place. It can only parse HTML, CSS, and JS. Can we have our cake with a CMS and eat it too with a fast site?

That is the goal of the JAMstack. Javascript, APIs, and markup. The basics.

Let’s start with Javascript.

An overwhelming majority of developers today based on a Stack Overflow survey would rather work with javascript than any other language. With libraries like React and Vue you can build amazing user interfaces for the web. Built on top of libraries are frameworks like Gatsby, Next.js, SvelteKit, and many others.

The tools you need to get up and running quickly and easily are readily available. Whether you need a simple static site generator, or a hybrid approach with static and server side rendering, there is a framework for you.

Once you have your JS tools selected, it’s time to move on to APIs.

APIs are really exciting to me. You can easily move data around the web from one microservice to another. You don’t have to “roll you own” thing every time you need new functionality. Find the best in class solution for your needs, and access it via an API. This includes your data.

Coming from WordPress, sometimes it is hard to wrap your head around the difference between your content and the display of that content to an end user. The template files in a WordPress theme are a hodgepodge of markup and database calls for the content that you need. There is no separation of concerns.

The paradigm shift occurs when you start to see all of the content in the database as the data layer, completely separate from the front end display. All of a sudden, all of your content simply becomes JSON data like any other API. Now you have full control of how you want to access and manipulate that data, without worrying about how it looks or any interactivity.

It is just data.

Granted, it is easily authored and published data. Publishers are familiar with a CMS that powers over 40% of the web. They know how to use it to write and publish their articles, posts, and pages. They don’t like change. And by thinking of WordPress content as simply an API for data, they don’t have to.

Since WordPress is now just data, we can access that data via an API from any type of front end framework that we like. We can also integrate other APIs from around the web into our application and build exactly the site we need.

WordPress is no longer the huge monolithic controller of every aspect of a website. It performs what it does best as the CMS to enter data into. We have other tools that are better equipped to create a fast, secure front end experience for our site visitors.

Finally, let’s move on to markup.

Markup is the actual HTML and CSS that gets rendered by the browser. All of our tooling and APIs get combined into plain markup that the browser can parse. The build process creates static HTML files that can be served from any server.

This is relevant to WordPress because there is no longer a database and PHP layer for the front end to have to go through. No need to worry about setting up caching with plugins or on your server because there are no database queries to cache. In fact, the database is effectively unreachable by the front end of the site once an end user sees it.

This leads to some huge benefits for going headless.

Speed, scalability and security.

We all want fast websites. Google wants fast websites. Our users want fast websites. In today’s mobile first world where our data can be accessed from anywhere, users want things to load quickly. Even milliseconds of delay can be the difference between someone converting and someone bouncing from your site.

Front end frameworks use things like code splitting, image optimization, inlining critical styles, lazy-loading, prefetching resources, and more to serve blazing fast websites. And all of this can be done automatically at build time. No plugins to install and configure.

You don’t need complex scaling for your server environment to handle large traffic spikes. Since the only thing being served are static files you can easily serve them through a CDN network to deliver an almost instant experience for the end user, no matter how many site visitors you have.

What about security? Since there is no server and no reachable database there is nothing to take down. You don’t have to worry about malicious requests or DDOS attacks. You don’t have to spend valuable time, energy, and money hardening WordPress with a combo platter of security plugins and firewalls.

All this sounds great, but what are the downsides?

The biggest downside is the loss of any WordPress plugin that affects the front end of your website. At least for now. One of the powers of WordPress is its giant ecosystem of open source plugins. Using a front end framework makes it difficult and sometimes impossible to use plugins we all know and love.

However, solutions are being created that allow for the use of these plugins within a headless environment. So you can use still use a plugin like Gravity Forms to handle form submissions. As time goes on and we get deeper into headless, more and more solutions will be created to make plugins compatible.

But before we get too disappointed, its worth taking a moment to reevaluate if we need to be using all of the plugins that we do. Since WordPress is now just the home for our data, that opens up a whole new world of solutions that might be a better fit for our project.

What if instead of reaching for a plugin, you integrated with the best tool for the job via an API? Forms, memberships, payments, e-commerce, and more. Through the power of APIs you can connect together the perfect solution for your project. That sounds pretty cool to me.

Another thing to consider is the loss of WordPress themes.

All of the front end display is controlled by the front end framework. It will take some level development skills to get a static site built. I wouldn’t call it a “no code” solution. But that just means you need to use the right tool for the job.

If you have the budget and the need for a fast and secure site, then the costs associated with building it are more than justified.

Why Headless Matters

Headless is another tool a developer can add to their toolbox. It might not be the best solution for every project, but it just might be perfect solution for one of them.

I’m excited about the possibilities an API driven world opens up for WordPress as a CMS. As a developer you are no longer locked in to one specific technology stack on every single project. Your client can get the CMS they need, and you can develop using the latest cutting edge technologies in web development.