Headless WordPress: what is it and do you need it?

At Managed Server, we are big supporters of WordPress and its ecosystem. We also use it for our sites because we really find it the best content management system, as the stats keep showing year after year. It's open source, versatile, and in a nutshell, it's incredibly easy to see why it powers over 40% of all websites on the internet.

With how large the ecosystem and developer community surrounding WordPress is, it's no surprise that people use WordPress in different ways. One such approach is using WordPress as a headless CMS, for short, named Headless WordPress, which is becoming more and more popular.

In this guide, we'll break down everything you need to know about WordPress Headless, its pros, cons, and more from our team's firsthand experience.

What is WordPress Headless?

To understand WordPress Headless, you need to know what monolithic WordPress is. Monolithic, o WordPress in its traditional form, is WordPress as you know it. It is a content management system that you can use to manage all the content on your site.

In general, WordPress has the backend (the content management system) and the presentation layer, which allows you to design your website. However, Headless WordPress sites are those that simply rely on WordPress as their content management system and use a different frontend stack to display the content.

This allows for greater flexibility in terms of development. Basically, with the help of the REST API, you could use WordPress for its content management functionality by pairing it with a separately created frontend in a framework like Vue.js o React (just to name a few, there's a whole host of other frontend frameworks and tools available).

WordPress is considered a coupled CMS architecture because all front-end editing tools and back-end content management (editing) features are coupled. This allows teams of developers, publishers, copywriters, and more to manage both the presentation layer and the content. As opposed to the Headless WordPress websites that follow a decoupled architecture where the presentation layer and the content are, as the name suggests, decoupled.

REST, GraphQL and flat file integration

A headless CMS configuration uses APIs and CDNs to render content. And there are currently three options: the REST API, flat file integration, and GraphQL.

WordPress uses the REST API to allow you to connect the frontend to the CMS. A REST API is simply an application programming interface that follows the constraints of the REST architecture, providing a uniform interface that allows servers and clients to transfer data between each other. REST allows developers to expose and use specific data, if the REST endpoint does not have the data directly available, additional development will be required.

Another alternative is GraphQL (QL is short for Query Language). GraphQL makes it easy to query APIs with specific fields and relationships, just like you would with a database. This is a significant improvement and there is a plug-in that makes it a GraphQL API available on WordPress . This may mean that no additional development is required to leverage the content of the CMS since GraphQL already has access to it, the hardest part is asking for the correct and efficient queries to get it.

The other option is flat file integration. Flat file integration allows you to export data normally provided via REST or GraphQL as a .JSON file, thus allowing the server to cache them and they don't have to be generated on every request, making it much faster. Using this method will automatically generate a new set of .JSON files with each database change. This is usually a bespoke implementation and not just a plug-in. Therefore, a developer is required to set it up.

The advantages and disadvantages of WordPress Headless

Now that you know what WordPress Headless is and how it is different from a WordPress setup conventional, here are the pros and cons you should know before making a decision.

Flexible development, from scratch.

While still using WordPress as your content management system, WordPress decoupling gives your developers the flexibility to build with their favorite front-end technologies, such as frameworks like next.js . At the surface level, this means much more freedom to build.

On the surface, this is fantastic. But it also means you end up reinventing the wheel for basic features, like sitemaps and permalinks, making sure that live previews of post and page content work.

And you lose the most of the The editorial workflow that WordPress is known for. Setting up new pages often becomes much more complicated and requires standby developers to debug when things don't they work.

Building mobile apps with a WordPress backend

An often overlooked use case is that when you decouple WordPress, using it exclusively for the backend, you can build mobile apps.

Apps are complex, much more than building websites from scratch (i.e., with or without WordPress), so if you end up going this route, while the content will be API-based, much of the rest will rely on device functionality. native with the help of frameworks like React Native. Here's a great comparison of different ways to build mobile apps from AppPresser's Scott Bollinger. One of them is, as you may have guessed, AppPresser, which is a great implementation of this for those who want to get started right away. It is, of course, powered by WordPress, using WordPress plugins, themes, and REST APIs to power native / hybrid iOS and Android mobile applications.

Starting with a solution like this will save you weeks if not months of development time and ultimately builds on their team's years of experience in-house from years of working on customer projects and testing the platform in production to perfect it.

Better performance, with compromises.

There are three main ways to develop Headless

1. Client side: everything is built on the browser using javascript with the content loaded from the server during login. For example, using React as an engine gets the data through, for example, the REST API. When the page is modified, there is a request for more data to the API and a new page is created on the client. Most often used in single page applications (SPA)
2. Static published: everything is already compiled and exported as HTML, CSS and JS on the server. Since it only serves static files, not dynamically generating the page, this can be stored on a server or very low-powered CDN. This method is very fast. This is often done with something like Next.js. When the page is edited, a new HTML page is downloaded from the server and displayed. Used most often on sites that don't change often, such as brochure or documentation sites.
3. Isomorphic pages: the first web page accessed is Server Side Render (SSR) as HTML, but all other subsequent pages are generated on the client side if the client is able to do so. If the client is unable to generate the page, it will request it from the server. Most often used on Progressive Web Apps (PWAs), highly dynamic sites, or those that need to serve older web browsers. Often a framework such as Svelte.kit.

Methods n. 1 and n. 3 might use flat data files to generate the HTML, making them comparable to a static published site, but using REST or GraphQL will slow them down slightly as it may have to generate JSON content with every request.

If elements such as user-generated content (forms or comments) are needed, these three ways of working become much more complex than in standard WordPress. Take for example a contact form, the form must be built to work on the client side and be able to send its information via Javascript / AJAX to the server, where it is then checked, disinfected and placed in the contact form plug-in management system. As this is a completely different way of working, it cannot rely on the contact form plugin creator to provide this or what things like honey pot and other spam protections will continue to work. You may need a developer to create a REST endpoint and make it work as needed. Much more complex.

Comments are, in theory, much simpler because REST endpoints already exist, but you will still need a developer to allow you to retrieve approved comments and present them in a threaded layout, upload new comments in the approval process, and of course , handle spam. When developing Headless, there is still a lot to do to achieve the same goals that emerge from the patterns with WordPress or are possible with some plugins.

The perception of a major safety? 

There is a lot of misinformation about WordPress Headless security. Performing a static site setup with a CDN is a good preventative measure against DDoS attacks. But ultimately, any server can be the victim of a DDoS attack if you don't put the necessary systems in place (eg Cloudflare, etc.). The decoupled WordPress setups work with WordPress installed on a separate domain or subdomain, with the frontend on the standard domain.

For example, if we were to use this website, we would continue to use ManagedServer.it as our site publicly accessible while having wp.ManagedServer.com set up as an area where our team can publish blog posts and manage the parts of the site that they can.

And for example, using a Next.js frontend as an example would mean the ability to use SSR (server-side rendering), where the HTML of the page is generated on each request, or SSG (static generation), where the HTML of the page is generated at compile time. Static generation allows HTML to be reused for each request by allowing it to be cached from a CDN.

Either way, the presentation layer still communicates and requests content from the content layer running WordPress. This means that the area where you host the content management layer for WordPress Headless setup would continue to run WordPress.

To sum it up, the answer is safety is better on Headless WordPress websites than sites that work with the conventional setup is that it can be. Simply put, because it is a less common configuration. What we mean by this is that the real reason why some try to paint the perception that there are security issues with sites running WordPress is that so many sites are running WordPress and things are completely flexible; so obviously you can build or install something that isn't reliable, the same is true if you build with headless and pretty much any other stack.

When you work with a WordPress hosting provider that offers security, scalability, and performance expertise like we do at Managed Server, it's still possible to keep your sites secure without sacrificing everything you can do with WordPress, having to go through expensive development. costs to rebuild from scratch.

Other downsides you may encounter with Headless

The costs of WordPress Headless

We mentioned this briefly already, but in short, Headless WordPress can get quite expensive. Not just in terms of development costs, but perhaps more importantly, of time. 

Your group loses the ability to move quickly and iterate without having to rely on in-house engineers (or an agency).

For fast-paced teams who don't see their sites as static, this is a trade-off that ultimately isn't worth it. We have seen firsthand how 8-digit companies, which clearly have the resources to manage WordPress Headless internally, choose to move to a Headless setup and eventually come back because what they couldn't afford was the waste of time, flexibility. to move quickly and ultimately give more than a handful of people on their team the control to work on their site.

Good developers who know what they are doing can be hard to find

WordPress Headless is still a relatively new setup. So while finding JavaScript developers familiar with JavaScript (and frameworks like React, Vue, Svelte, Gatsby) isn't particularly difficult at all - and perhaps even easier than finding great WordPress developers right now, those who are actually familiar with it. Integrating the frontend level with WordPress in a conventional way that adheres to all best practices tend to be harder to find.

Not always faster than edge cache with Full Page Cache

There are easier, and perhaps better, paths to a faster website.

Most companies considering headless architecture should fix their hosting before making what is a significantly more complicated decision. Not only is this much easier to do, but you will also quickly see significant improvements without a huge upfront investment. Without investing in rebuilding your site and giving up all the benefits of your WordPress installation in its current state.

When Should You Avoid Headless WordPress?

As a general rule, WordPress Headless isn't suitable for most businesses building with WordPress. In short, those who:

• You want to avoid keeping two separate layers (the content layer and the presentation layer).
• I don't want to give up on the editorial and content management workflow that WordPress is known for.
• Give their team the control and flexibility to work without having to constantly rely on your developers.
• You want to save resources (time and money).
• There are no experienced developers available to make the correct choices about how the system is built.
• Are you looking to hire temporary workers or hire an agency to develop your site with an eye on subsequent future developments?

Who is WordPress Headless suitable for? 

Headless WordPress can be a good option for your team if:

• Your development team is well versed in building JavaScript frameworks, and finding a WordPress developer is not an option (for whatever reason). But also wants to continue using WordPress as a content management system, WordPress Headless can be a good option.
• Your team wants to get specific results, such as continuity between the design of an already built SaaS platform, which would make it more difficult to rebuild and maintain them in WordPress. In this case, separating the content and presentation layer can be a good option.
• You are determined not to build within the confines of WordPress themes and do not specifically rely on any additional functionality offered by plugins.
• As an employer, you want to continually train your technical staff with the latest skills and know that by providing them with this knowledge, they are more likely to stay with you longer.
• Your goal is to perform optimizations of n -th degree on all parts of the stack.

Report after action: evaluate the absence of a head as a solution

Some want to explore Headless because it's the brilliant new thing few others are working with. Not because it is really the best solution for a specific problem that would otherwise not be achievable. As a byproduct, most sites that take the headless approach fall into the category of excessive engineering without the need. 

It goes without saying that there are also interesting WordPress Headless implementations and scenarios where it can be a great choice. Those where choice is what allows teams to create incredible websites that drive the outcome they are trying to achieve.

Are you still wondering if WordPress Headless is in line with what your team is looking for? Feel free to book a call with us and we will be happy to talk about the issues you are having and considering the WordPress Headless implementation to fix.

Or, if this guide has already answered all your questions and you are ready to try the Managed Server approach:

Interested in managed hosting which is empirically faster? Try our approach to WordPress hosting:

• Scalability: in real user workload tests, the Managed Server delivered an average response time of 65ms, 4,9 times faster than second-best response times.
• The fastest overall load times: Average page load times of 1,26 seconds put us at the top of the list of global WebPageTest results.
• The fastest processing speed: Managed Servers deliver never before seen database speeds, processing 2,44 times more queries per second than average and running PHP 2,6 times faster than second best!
• Perfect safety and uptime: With 100% uptime on all monitors and an A + rating on our SSL implementation, you can rest assured that your site is online and secure.