Headless CMSs are gaining more traction as developers look for web development solutions that offer more freedom and interoperability. But what exactly is a headless CMS?
To help understand exactly what a headless CMS is, I’ll quickly break everything down into simplified terms.
If you look at a vanilla WordPress setup, you’ll find that it comprises two components:
- The admin or dashboard: This is where you create your content, add pages, upload media, and manage the site.
- The front-end: This is the part that visitors see when they visit your site. The browser assembles the front end using PHP, JavaScript, images, data, and other assets from WordPress.
As you can see, these two components are coupled together into one software stack, and this can pose a problem sometimes. The process of assembling the page takes time. The bigger the site, the more time the browser takes to render it.
With a headless CMS, these two components are decoupled from each other—the front-end can be anything, while the back-end acts as a standalone service accessible via an API or SDK.
A headless WordPress site uses WordPress to manage content, but allows the developer to use their preferred front-end stack to display the content to a site visitor.
There are many Headless CMS solutions out there—Contentful, Netlify, ButterCMS, and so on. Let’s take a look at one that is tailored specifically for building WordPress sites.
Example of Headless WordPress
Strattic is a hosting platform that allows you to use the serverless architecture for the purpose of creating fast, optimized, and secure WordPress sites. It was acquired by Elementor midway through 2022.
Before we start testing out the CMS, it’s important to understand the workflow of a typical headless WordPress. There are three components to working with a headless version of WordPress:
-
Contained WordPress Environment: A typical WordPress where you can log in to the admin dashboard and manage your site.
-
Static Preview Environment: A preview version of your site that you can use as a kind of staging site. This is where you’ll push site updates and test whether they’re working.
-
Static Live Environment: The live site itself. After making changes and confirming that they work, you’ll then push the changes to the live site.
When you create a page, for example, Strattic’s servers will combine all the assets (images, data, etc.) into an HTML file, store that on their servers, and deliver it via a CDN. That way, when your user goes to your site, they’ll get the pre-generated HTML version of your site from a CDN.
We’ll go over the benefits of this setup later on in this article.
Coming back to Strattic, after creating a site there, you’ll have three different sections in your site details section—the WordPress connection information, preview site connection information, and live site connection information.
Here we’ve got our WordPress site connection information. This is the WordPress setup on the actual Strattic server. You should know that while you’re working there (in your normal environment in the dashboard), your live site will remain active.
Next, you’ve got the URL of your preview site.
When you make changes to your site in the normal environment, Strattic pushes the changes to the preview site. So the preview is no longer WordPress, but just the output in a preview state.
You can use the preview as a staging site to inspect all the changes you make to WordPress and make sure everything works as intended before pushing it to the final component, which is the live site.
This is the version of your site that users will see and interact with. Strattic assigns you a temporary stratic.io domain by default, but you can connect a custom domain if you have one.
Editing the Site in WordPress
You can install WordPress in your Strattic environment by clicking the Edit in WordPress button on the sidebar of the homepage.
That’ll spin up WordPress and redirect you to the typical WordPress setup workflow.
Go through the steps and provide the information required of you in each step. You’ll then be asked to sign in to your admin dashboard. There you can create posts and pages, install plugins and themes, and manage your website just as you would in a vanilla WordPress setup.
Benefits of Using Headless WordPress
Traditional WordPress is favored by non-technical users as it doesn’t require any knowledge of coding. But for experienced developers who want more freedom and a better developer experience, WordPress might not cut it.
If you’re one of those developers, you might want to consider decoupling WordPress from the front-end. Let’s go over some of its main benefits.
Supports More Tools, Frameworks, and Libraries
With vanilla WordPress, you’re forced to stick with the technologies built into the stack. This architecture hinders you from integrating tools and libraries that you might be more experienced in.
By contrast, headless WordPress is technology-agnostic, so it can integrate with a wider set of libraries and tools. You can build websites with your favorite JavaScript front-end framework and tool stack, and even integrate it into an existing workflow without sacrificing what you’ve already built.
Better Speed and Performance
WordPress is built around PHP. Since each page is produced from data kept in a database, they load more slowly than a static website created using HTML files. When plugins are included in the equation, the website becomes even more sluggish.
As you know, headless WordPress works by pre-generating HTML and caching it in CDN servers around the world. This setup dramatically improves the speed by which your site is delivered. Furthermore, you can integrate your back-end with a Next.js or Gatsby front-end to enjoy performance benefits such as server-side rendering and out-of-the-box SEO options.
Better Security
Vanilla WordPress is a huge playground for hackers. In fact, hackers can carry out brute force attacks or overload your website with DDoS attacks simply by accessing your website’s /wp-login.php file.
On the other hand, a site with a headless architecture is not susceptible to those kinds of attacks. WordPress is no longer being used to output the data, so the same vulnerabilities plaguing WordPress cannot apply.
In addition, the API-first setup of headless WordPress allows you to add cybersecurity services and tools to repel any other forms of attack.
Conclusion
With the headless approach, you get huge performance gains as well as architectural freedom. On the flip side, you have to grapple with complexities that might be too much to handle if you’re a novice developer or non-tech person.
Headless WordPress is by no means going to replace traditional WordPress. It’s more of an option for businesses with a requisite developer team that want to adapt their platform or service to serve new use cases.
Go headless if you have what it takes. Make sure you’re doing it for the correct reasons before you commit to it. You won’t regret it.