(And why do users want to use a Page Builder with Headless WordPress?)
Modern, Composable WordPress
WordPress has evolved so much over the last few years, between Gutenberg and the Full Site Editor, there is a lot of choice in terms of how to build a website with WordPress these days. Elementor and Divi also have their use and their market – and fill a low-code/no-code gap; with Elementor being the #1 page builder in all of WordPress.
Composable WordPress is slowly becoming a norm, with the continued improvement of the Rest API and implementation of WP GraphQL to expand the technology set underneath WordPress, has allowed for some technologies and approaches to the web to be trickled down into WordPress where before, these approaches haven’t been either viable or were a technical niche that only a few seeing the “Headless” buzzword would be interested in. The concept of ‘Composable WordPress’ signifies a significant evolution in the way that WordPress can be utilised. Rather than being constricted within its traditional role as a front-end and back-end tool, WordPress can now be relegated to function primarily as a back-end content management system. This innovative shift opens the door to a plethora of new opportunities for developers and users alike. With this new approach, it’s now feasible to integrate WordPress with a broad array of modern tools and front-end interfaces. This not only enhances the robustness and versatility of the websites that can be created but also significantly improves their scalability. In essence, this advancement in WordPress technology paves the way for the design and development of websites that are much more powerful and capable of scaling to meet growing demands.
Modern, Composable WordPress WordPress has evolved so much over the last few years, between Gutenberg and the Full Site Editor, there is a lot of choice in terms of how to build a website with WordPress these days. Elementor and Divi also have their use and their market – and fill a low-code/no-code gap; with Elementor being the #1 page builder in all of WordPress. Composable WordPress is slowly becoming a norm, with the potential to marry WordPress with other approaches to front ends becoming more and more common and easier to achieve.
Do Page Builders Work with Headless?
Short (and I guess long answer in a way); is no.
Page builders don’t really have seamless ways to translate the pages and content you create in them to a front end via either the RestAPI or WP GraphQL.
Even if there WAS a direct route to do it, the coding behind those pages isn’t really meant to be edited in away that things like a Block Theme, a classic PHP based WordPress theme or a JavaScript based site are.
The code is more or less spaghetti code, and can be confusing as to why things were done a certain way or why they are there just on surface value. In the editor, this isn’t really an issue or even at front of mind, as the end goal with a page builder is a drop and drag experience that is designer friendly and can help you build a website from nothing, into something that is something quite nice to look at or interact with; at the end of the day.
At a super high level, Headless WordPress works by performing an API call either with get or post, to query information from WordPress. You can get really into the weeds with this by getting ALOT of info from how you shape these queries, but it is more designed for getting Data from ACF, posts and pages (a lot like this blog actually! This site is a Headless site), user data and custom post types from WordPress.
Headless is more about leveraging the core abilities of WordPress ITSELF, rather than the add-on potential for things like a page builder.
What Do Page Builders offer over Headless?
Page Builders like Elementor and Divi, have their place in the WordPress community. They offer a simplicity to design and a low-code drop and drag model that provides quick design ability to non-technical users and an ability to rapidly put together sites as an Agency to provide pleasant design and usability results back to their end clients. Modern Headless can be done in a few ways, with the Rest-API, WP GraphQL Plugin from Jason Bahl, as well as the Block Data API from WP VIP; whatever way you pick, you’ll still end up with an ability to query WordPress’s data in some fashion, manipulate it and work with it as a developer. But that is the main hiccup; Headless has naturally a higher barrier to entry just due to the development requirements. Unless you know how to query an API endpoint, and work with JavaScript professionally, it can get quite difficult to use, and now-a-days with Gutenberg progressing the way it is and with the FSE (Full Site Editor) & Block themes, from what I have seen professionally there is plenty of potential to make an optimised WordPress site without needing to go Headless just to get better performance overall.
Page Builders do have an inherit trade-off with large amounts of scripts loaded on page for components you might not even be rendering, or bloat with add-on plugins that, while they are designed to enhance or expand what the page builder can offer, generally can add unintended performance degradation with more and more users hitting the site and more and more issues with admin-ajax requests or dynamic interactions with the Database that a non-technical or simply unaware user might not even be aware of, and just translate this into poor performance in the wp-admin.
Page Builders can also add more creeping expenses that can be harder to justify financially in the long run. Take Elementor Pro for example; a lot of cool features are price locked, but other plugins built to provide add-ons will also have pro features behind expensive single use licences or unlimited use licences with yearly renewals. For non-American developers with a vast majority of these plugins priced by USD pricing, once you take into account the cost of Elementor Pro and a few of these add-ons, they can nearly add up to the yearly cost of your hosting bill.
Why Go Headless?
There are many reasons as to why you would want to consider moving to Headless WordPress vs migrating to another platform. In the past, if WooCommerce was slow, you would just go to Shopify, if the blog wasn’t working you would move to Squarespace. Now-a-days with cost cutting and infrastructure changes evolving the site you have can be more viable than a lift and shift.
Headless WordPress has key points it tries to help and address for customers. Firstly most developers that are experienced in the JavaScript framework space are familiar with how fast Staticly Generated Sites built with SSG (Static Site Generation) side of frameworks like Next.JS and Gatsby can be, as well as the power of implementation of server side features with Server Side Rendered (SSR) approaches for more complex and dynamic sites. Headless WordPress in general, opens up avenues for sites to get creative with, that isn’t just the obvious of the performance side. For starters, an interesting use of Headless WordPress that I have seen, is implementation of the blogging side of WordPress for a change log in a game launcher, and having the game launcher call the blog posts and change log updates for people to ingest either in the launcher or on a dedicated front end. Another interesting I have seen is cross-platform, cross functional Applications with React Native, that run on nearly every platform and are running off of a WordPress based back-end with ACF, React Blocks and a lot of the core logic built into WordPress; and then the traditional client side logic built into the Application itself. WordPress has a great user authentication and management system built into it, has plenty of features for storing and handling user data, gated content and video playback so why not use them!? Outside of this, personally a preferred usage of Headless WordPress myself is converting admin-ajax heavy WordPress sites, or more dynamic sites that are chewing up hosting performance, and re-doing them Headless to gain a better front and back end experience for both the end user and the end business owner/client.
I have been making the point to a lot of customers and clients, that Gutenberg and the current Block API, teaches some decent skilling that is cross compatible with Headless development; since the block API works off of React, learning those skills, even rudimentary, allows you to wade into the Headless pool far more confidently thank you did before. Gatsby also offers a React based Gutenberg block tool plugin, though it hasn’t been updated since 2020; and of course there is also the @faustwp/block-editor-utils package from WP-Engine and it’s approach to handling Gutenberg Blocks as React Components.
Overall, while there is a technical jump into Headless, I do feel that while Page Builders do offer convenience to a wider audience, their trade off with I have linked across this post a few examples and references to material across the web, as well as I have some references below to some further reading that might be of interest if you are considering taking a deep dive into Headless WordPress.
Glossary:
- SSG (Static Site Generation): This is a process where a website is generated at build time, creating static HTML files. This means that the site’s content does not change unless a new build is executed. It’s a popular method for enhancing site performance and security.
- SSR (Server Side Rendering): In SSR, the server generates the HTML for a page in response to each request. This means that each user (or each request) gets a fresh, fully rendered page, which can be beneficial for dynamic content and SEO.
- Composable WordPress: This term signifies an evolution in the way WordPress can be used. Instead of being confined to its traditional role as a combined front-end and back-end tool, WordPress can now function primarily as a back-end content management system. This opens the door to a range of modern tools and front-end interfaces, enhancing the versatility and scalability of websites created with WordPress.
- Headless WordPress: This refers to a setup where WordPress is used as a back-end content management system, but the front-end is decoupled and replaced by a modern technology stack. This approach allows developers to leverage the robust content management capabilities of WordPress, while also enjoying the flexibility and performance benefits of other front-end technologies.
References & further reading:
Headless WordPress and Content Management Systems – WP Engine
Using Headless WordPress with Next.JS and Vercel
How to use WordPress with React to Create a Headless CMS for Your Web Application
