What is Headless WordPress?
When we talk about a “monolithic CMS,” we’re referring to the platforms that most of us are familiar with. There is a frontend and a backend, with the edits you make on the backend visible for the user on the frontend.
This is how the majority of small or mid-sized businesses operate, using a traditional, out-of-the-box CMS setup to run their website. But it’s not the only option.
Increasingly, developers are opting for something called “headless WordPress” because it allows businesses to unlock a superior performance that gives their visitors a next-level experience.
Headless WordPress: A Brief Overview
If you’ve been moving in developer circles, you might have already come across this term but aren’t sure exactly what it is. A headless CMS, with WordPress being the most popular example, essentially disconnects or decouples the frontend and backend.
There are various reasons why you might want to do this. By separating the editor from one specific view (i.e. your website), you can use the editor you know and love to push content to third-party platforms via an API, whether Facebook, mobile apps, or more.
While this can be useful for marketers who want to avoid using too many platforms or embrace emerging technology, it’s likely not worth it for this reason alone.
The true value of a headless WordPress for businesses is in providing superior performance for the end user.
Google’s Core Web Vitals
We are all aware that speed is important for user experience and SEO. But do you know just how important it is?
Google has been steadily applying algorithm updates to reward the websites that provide a better user experience. A substantial part of this experience is how fast your website loads, and Google looks at key metrics to determine this.
The metrics that you need to worry about are:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Let’s take a quick look at each.
Largest Contentful Paint
This is all about speed, gauging the boots-on-the-ground reality from the user’s perspective. Once a visitor clicks a link, this will begin timing how long it takes before they can see the page.
First Input Delay
First Input Delay focuses on the time it takes for a user to actually interact with a page, such as clicking a navigation button, entering information, adding an item to a shopping cart, etc. It is especially important for a login, signup, or ecommerce page.
Cumulative Layout Shift
Finally, you have the CLS, which measures how much movement there is on a web page while loading. The classic example is when you try to click on a link and at the last second the page jumps and you click on another link. Extremely frustrating.
While the CLS is more to do with the images and specified dimensions on your web page, what do you notice about the other two core web vitals?
They are determined by speed.
What’s in a Second?
When talking about websites, a second is a long time. Think about the Olympic 100-meter sprint. If you complete it in over 10.05 seconds, you won’t even qualify for the race. If you run it in 9.57 seconds, you’ve set a new world record and will become world famous.
Every time you look at the statistics for web speed times, split-second performance becomes more and more important.
In 2018, Google said that if a page load speed goes from one to three seconds, the probability of bounce increases 32%. Portent, in a study that was updated in 2022, says that a website that loads in one second can enjoy a conversion rate that’s three times higher than a website that loads in five seconds.
With Google putting more emphasis on Core Web Vitals, you can expect these statistics to become even more exacting.
How a Headless WordPress Helps
In a traditional setup, web pages are rendered dynamically, meaning that the hosting server puts together a HTML page every time a request comes in. To achieve this, the server must run PHP and MySQL processes to fetch all the resources, stick them together, and show them to the user.
This can result in a slower experience for the user, which affects your Core Web Vitals. With Headless WordPress, you can query data from WordPress in a static HTML (or JavaScript or CSS) frontend, drastically improving the performance and user experience.
In turn, this will have a direct impact on conversion, retention, and SEO.
Should I Use Headless WordPress?
Despite its many upsides, the decision to decouple your front and backend should not be taken lightly.
For example, unless you are a seasoned developer or have ongoing access to one, headless WordPress is not for you.
We’re not trying to be gatekeepers and keep the genuinely incredible benefits of headless WordPress from you. The simple fact is that, unless you have access to the expertise, it will likely be more trouble than it’s worth.
Necessary Dev Skills
When compared to a traditional website build, using a headless CMS presents new challenges.
Scripting Languages
For example, if you’re a new developer, you will likely have experience using HTML and PHP for WordPress development. In fact, PHP is used by about 244 million sites on the internet, which is unsurprising as it is compatible with all mainstream operating systems, has a required sign-in function for increased security, and is easily scalable since new servers can be integrated when required.
While it is possible to use any scripting language you wish when creating a headless CMS, PHP doesn’t produce the desired results when compared to JavaScript. This is because PHP is a dynamic scripting language which requires server processes to process the request, build the page, and then render the results. JavaScript and HTML, however, are static files that can be served incredibly quickly by a CDN or server that’s tuned for that purpose. For developers who aren’t familiar with JavaScript, this represents a serious roadblock when developing headless WordPress.
Connecting the Frontend and Backend
In order to push the content you create on the backend to the frontend (or whatever platform you wish), you will need an API to connect the two.
You have a few options when doing this, with the most common being the WordPress REST API. Whether ensuring endpoint consistency, maintaining response times, or guaranteeing security, there are a number of potential pitfalls when dealing with REST API unless you know what you’re doing.
REST API works well but for our money we prefer to use WPGraphQL, which is a higher-performant version that’s common in most newer JavaScript API development. It solves some of the problems prevalent in REST API, such as doing multiple round trips to fetch data required by a view.
Ensuring End Usability
The traditional platform is famously easy to navigate, but by splitting it up you risk losing a lot of that intuitive experience without access to an experienced developer. As a default, by decoupling the front and backend, you will lose the WYSIWYG editor with a live preview option.
This can be fixed, however, by using solutions like WP Engine Atlas’ offerings and the Faust.js Javascript Library, which restore this functionality.
Even so, you will inevitably lose some usability, particularly when it comes to plugins and themes. The out-of-the-box nature of WordPress plugins and themes simply won’t exist anymore as they won’t have any bearing on the frontend. For every plugin or theme you use, you’ll have to manually build the frontend functionality custom in almost all cases.
The bottom line is, at Pixel Jar, we are genuinely excited about the potential of headless WordPress but it does represent a cost vs. benefit scenario that you need to decide for yourself. For us, the positives outweigh the negatives, particularly when it comes to performance, and we want to ensure that the same holds true for you.
If you’re considering making the move to headless WordPress, feel free to reach out to us for a consultation. We will look at your specific situation and provide you with honest, open advice that allows you to get the full picture of what headless WordPress would look like for you and if it’s worth it.
