Headless CMS’s 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:
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 backend 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.
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 inside a headless version of WordPress:
Contained WordPress Environment: A typical WordPress where you can log into 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 to it and test whether the updates are working.
Static Live Environment: The actual live site itself. After making changes and confirming that they work, you’ll then push the changes to the live site itself.
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.
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.
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.
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.
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.
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.
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 server 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.