I wonder where headless WordPress will land. And by “headless” I mean only using the WordPress admin and building out the user-facing site through the WordPress REST API rather than the traditional WordPress theme structure.
Is it… big? The future of WordPress? Or relatively niche?
Where’s the demand?
Certainly, there is demand for it. I know plenty of people doing it. For instance, Gatsby has a gatsby-source-wordpress plugin that allows you to source content from a WordPress site in a way that consumes the WordPress REST API and caches it as GraphQL for use in a React-powered Gatsby site. It has been downloaded 59k times this month and 851k times overall, as I write. That’s a healthy chunk of usage for one particular site-building technology. Literally, every use of gatsby-source-wordpress is using WordPress headlessly—that’s just what it is/does. If you’re interested in this, here’s Ganesh Dahal digging deep into it.
And that’s just one thing, it doesn’t factor in entire companies and products dedicated to the idea.
What is headless an improve to?
The Gatsby integration makes a solid case for why anyone would consider a headless WordPress site. I’ll get to that.
Many advocate the reason is architectural. It de-couples the back end from the front end. It tears down the monolith. As a de-coupled system, the back and front ends can evolve independently. And yet, I’m less hot on that idea as years go by. For example, I’d argue that the chances of simply ripping out WordPress and replace it with another CMS in a headless setup like this is easier said than done. Also, the idea that I’m going to use the WordPress API not just to power a website, but also a native reading app, and some digital internet-connected highway billboard or something is not a use case that’s exploding in popularity as far as I can tell.
The real reason I think people reach for a WordPress back end for a Gatsby-driven front end is essentially this: they like React. They like building things from components. They like the fast page transitions. They like being able to host things somewhere Jamstack-y with all the nice developer previews and such. They like the hot module reloading. They like Prettier and JSX. They just like it, and I don’t blame them. When you enjoy that kind of developer experience, going back to authoring PHP templates where it takes manually refreshing the browser and maintaining some kind of hand-rolled build process isn’t exactly enticing.
Frontity is another product looking to hone in on React + WordPress. Geoff and Sarah shared how to do all this last year on the Vue/Nuxt side.
But will headless WordPress become more popular than the traditional theming model of WordPress that’s based on PHP templates that align to an explicit structure? Nah. Well, maybe it would if WordPress itself champions the idea and offers guidance, training, and documentation that make it easier for developers to adopt that approach. I’d buy into it if WordPress says that a headless architecture is the new course of direction. But none of those things are true. Consequently, to some degree, it’s a niche thing.
Just how niche is headless?
WP Engine is a big WordPress host and has a whole thing called Atlas. And that effort definitely looks like they are taking this niche market seriously. I’m not 100% sure what Atlas all is, but it looks like a dashboard for spinning up sites with some interesting looking code-as-config. One of the elephants in the room with headless WordPress is that, well, now you have two websites to deal with. You have wherever you are hosting and running WordPress, and wherever you are hosting and running the site that consumes the WordPress APIs. Maybe this brings those two things together somehow. The deploy-from-Git-commits thing is appealing and what I’d consider table stakes for modern hosting these days.
Another reason people are into headless WordPress is that the end result can be static, as in, pre-generated HTML pages. That means the server for your website can be highly CDN-ized, as it’s literally only static assets that are instantly available to download. There’s no PHP or database for server-side rendering things, which can be slow (and, to be fair, dealt with) since it adds a process ahead of rendering.
What’s “the WordPress way” for going headless?
I’d lump any service that builds a static version of your WordPress site into the headless WordPress bucket. That’s because, ultimately, those sites are using WordPress APIs to build those static files, just like Gatsby or whatever else would do.
That’s what Strattic does. They spin up a WordPress site for you that they consider staging. You do your WordPress work there, then use their publish system to push a static version of your site to production. That’s compelling because it solves for something that other headless WordPress usage doesn’t: just doing things the WordPress way.
For example, custom WordPress blocks or plugins might produce output that not only contains custom HTML, but CSS and JavaScript as well. Imagine a “carousel” block or plugin. That carousel isn’t going to work if all you’re doing is grabbing the post content from an API and dunking it onto a page. You’ll either need to go extract the CSS and JavaScript from elsewhere and include it, or somehow just know that isn’t how you do things anymore. You might attach the images as metadata somehow, pull them client-side, and do your own implementation of a carousel. With Strattic, theoretically, it’ll work as the HTML, CSS, and JavaScript is still present on the static site. But notably, you don’t have PHP, so Strattic had to hand-build form integrations, they use client-side Algolia for search, Disqus for comments, etc., because there is no server-side language available.
Shifter is another player here. It’s similar to Strattic where you work on your site in the WordPress admin, then publish to a static site. I believe Shifter even spins your WordPress site down when it’s not in use, which makes sense since the output is static and there is no reason a server with PHP and MySQL needs to be running. As an alternative, Shifter has a headless-only WordPress setup that presumably stays spun up all the time for outside API usage.
It’s fun to think about all this stuff
But as I do, I realize that the ideas and discussions around headless WordPress are mostly focused on the developer. WordPress has this huge market of people who just are not developers. Yet, they administer a WordPress site, taking advantage of the plugin and theme ecosystem. That’s kinda cool, and it’s impressive that WordPress serves both markets so well. There’s just a heck of a lot more WordPress site owners who aren’t developers than those who are, I reckon, so that alone will keep headless WordPress from being anything more than a relatively niche concept for some time. But, ya know, if they wanna put GraphQL in core, I’ll still take it kthxbye.
This is a great take on the topic.
I think an interesting discussion would be around when headless makes sense. WordPress being what it is, I think the focus should always be on those who are managing and creating the content. Headless makes that much more difficult.
To be clear, I love headless and I wish every new WordPress theme I created could be headless. It’s fun and it’s eas(ier) to set up a workflow and it’s
#thefuture. Sign me up.But if I can’t deliver a site that’s simple and intuitive for those working in the dashboard every day, what’s the point?
Also, I’d argue that difficult as it is to set up a webpack or gulp build for a non-headless site than it is to create a system for ensuring the headless outcome is consistently matching what the user is building in the backend of the site?
I mean, maybe. So, that’s why a conversation around when headless is a better solution than non-headless would be interesting.
“the ideas and discussions around headless WordPress are mostly focused on the developer”
I dispute this. Delivering markup without bloat, without unneeded static resources, without even a PHP engine, is faster, more secure, and better for accessibility and SEO. Basically, it’s better for clients and users.
Devils Advocate
A clean WordPress site that is built by competent developers using up to date PHP, along with an optimised caching system can be:
Fast
Secure
Accessible
Strong SEO
It’s not like you’re disadvantaging your clients/users by not going headless with WordPress.
hmm… At least in my country, headless WP does not really impact that much.
Most of the “developer” just use it because of how convenient it is to just use a theme or plugin that is already created by other people. The business model is just charging lower and deliver faster because you don’t have to do much for the developing itself.
WordPress loses too much convenience if it goes headless. Until the plugins has a way to support headless, I think it’s hard for headless WP to break out of its niche.
Great post! I’m really glad you categorized WP sites on Strattic as headless. I of course agree, but some people think our approach is not headless because of how the static site is deployed and rendered. But IMO the end result is what matters, and in our case the live static site is indeed headless.
One of our goals at Strattic is to bring the world of headless to non devs. ATM a lot of the approach around headless is super dev-oriented, which is fine but ignores the people who actually use websites on a day-to-day basis to manage content etc. With Strattic, both marketers and devs are happy since they get the environments that they want/need.
(BTW on Strattic the WP site spins down when not in use.)
And I totally agree with this: “Also, the idea that I’m going to use the WordPress API not just to power a website, but also a native reading app, and some digital internet-connected highway billboard or something is not a use case that’s exploding in popularity as far as I can tell.”
I keep seeing that as a reason to use headless and like you said, there aren’t many use cases for that type of functionality. Also, even if a WP site is running in the standard way, it still has a built-in REST API that can be used to send content to that billboard.
I’m really interested in Strattic because I’ve never heard of the service and it addresses the UX vs. DX rift.
With headless you kind of have to choose which one to focus on and that it’s a really smart approach to solving the issue.
Glad you like our approach Jamie!
at our company we are planning on going headless. Our site has been running on elementor for 1½ years now and it’s been great when it comes to quick customizations and experiments with our readers. The biggest downside is the pagespeed and bulk that comes with elementor. Our idea is to go with sveltekit and slowly transition parts of the website to Server side rendered sites by sveltekit. We are planning on overwriting the location for the nginx proxy to slowly test the transition site for site and taxonomy wise without working for months and doing an entire relaunch at once :)
Our biggest issue right now is that the permalink consists of just the post slug, so we can’t really address all single posts at once…
We have a lot of Elementor sites running on Strattic to solve exactly the issues you described. For example, here’s a case study about a company that moved their Elementor site to Strattic and it got 50% faster: https://www.strattic.com/coralogix-got-50-faster-on-strattic-without-an-extra-line-of-code/
We have a free trial so you can migrate a copy of your site to Strattic, publish a static version, and compare the speed to your current site.
Hi Miriam Schwab, thanks for the comment!
We currently use w3t total cache with our own redis instance (both wordpress and redis run on the same vps). The TTFB is already around 60-90ms instead of 1-2 seconds (when logged in). The biggest issues for our page right now are the Lighthouse scores which are a result of elementor. So the Jamstack route is pretty inevitable…
Thanks for the great post!
One correction:
Gatsby’s
gatsby-source-wordpressplugin does not use the WordPress REST API. That was true of previous versions of that source plugin, but the current version exclusively uses WPGraphQL to source data from WordPress.I agree with you @KellenMace.
Whereas, The plugin has been entirely revamped to enhance headless WordPress’s credibility!
I agree that pulling WordPress JSON data into native apps/electronic billboards/etc. is likely not very common. There is another use-case I think is worth considering here, though –
I’ve worked with companies who want to be able to pull data from WordPress, Salesforce, Shopify, and whatever other APIs, then use all of that data to construct the HTML pages that are ultimately delivered to users. This is what Gatsby refers to as the “content mesh”.
To do that in traditional WordPress, you would need to ping those third party services from the WordPress server, cache the response data, write custom code to bust the cache and regenerate that data periodically, etc.
With a headless approach, sourcing data from multiple APIs like that is more easily managed. And with features like incremental static regeneration in Next.js, end users never have to wait around for stale cache data to be regenerated– that happens async on a periodic bases to keep the data fresh.
This is certainly not applicable to sites that only use WordPress’ data. For those that need to source data from multiple external services though, I think it can provide a UX improvement.
It’s a shame a little more research hasn’t gone into this post, I think it’s super important to let the reader know what the service in question does rather than guess…
That aside, we run a managed headless host and our main clientele are those that want WordPress blogs on their Shopify stores. This is a massive audience. Our aim is also to target non-WP developers and focus on JavaScript developers to give their clients the best CMS without having to know WP.
People tend to see WordPress as a website builder. First and foremost, WordPress is a great system for blogs. With the new headless plugins, we can now outsource this well thought-out system without using WordPress as a frontend.
You gave a perfect example: wordpress as cms in an e-commerce system. You unite two worlds.
There is no doubt there’s a trend towards headless and cloud. More often than not, a lot of devs just follow the hype factor.
Don’t get me wrong, I love headless, I’d rather code in JS than PHP and I’m more than happy to go all in with View.js, server less and whatnot.
Nevertheless, sometimes all you need is just a website that shows content, maybe allows to take orders. And WordPress native is a great fit for that.
As explained in CSS Tricks is a WordPress poster site article, WordPress with custom theming/coding is often the perfect answer to the task at hand.
How many external services (scattering your content) and glue code would you need to maintain content pages, blog posts, a forum and an e-commerce?
WP does all this almost out of the box. You just need to throw some custom templates and CSS, slightly edit some logic here and there if required and that’s it.
Just look at what people do: they host their store on Shopify and they end-up deploying a WordPress for their blog anyway.
WP is far from always being the answer, but if I’m going headless, then it means that I probably should find another backend.
I switched my WP blog to headless w/React for pretty much exactly the reason you mentioned – I like React. Actually it was when I was first learning React during lockdown last year (I know, I’m late to the party), and I wanted to work on a real-world project. I’m happy with the result, and my next step is to rewrite it with NextJS.