Headless CMSs are gaining more and more popularity 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 WordPress resources.
As you can see, these two components are coupled together in a software stack and this can sometimes be a problem. The page assembly process takes time. The larger the site, the longer it takes for the browser to display 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 accessed 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 content to a site visitor.
There are many Headless CMS solutions: Contentful, Netlify, ButterCMS and so on. Let’s take a look at one tailored for building WordPress sites.
Headless WordPress example
Strattic is a hosting platform that allows you to use serverless architecture for the purpose of creating fast, optimized and secure WordPress sites. It was acquired by Elementor in mid-2022.
Before you start testing your CMS, it’s important to understand the workflow of a typical headless WordPress. There are three components to work within a headless version of WordPress:
-
Content WordPress environment: A typical WordPress where you can access the admin dashboard and manage your site.
-
Static preview environment: A preview version of your site that you can use as a sort of staging site. This is where you will push site updates and see if the updates are working.
-
Static live environment: The real live site itself. Once you’ve made the changes and verified that they work, you’ll push the changes to the live site itself.
When you create a page, for example, Strattic’s servers will combine all assets (images, data, etc.) into an HTML file, store it on their servers, and deliver it via a CDN. This way, when your user logs into your site, they will get the pre-generated HTML version of your site from a CDN.
We’ll look at the benefits of this setup later in this article.
Back to Strattic, after you create a site there, you will have three different sections in the details section of your site: the WordPress connection information, the preview site connection information, and the live site connection information.
Here we have information about connecting to our WordPress site. This is the WordPress setup on the actual Strattic server. You should know that while you are working there (in your normal dashboard environment), your live site will remain active.
Next, you have your preview site URL.
When you make changes to your site in the regular environment, Strattic pushes the changes to the preview site. So the preview is no longer WordPress, just the output in a preview state.
You can use the preview as a staging site to inspect all changes made to WordPress and make sure everything is working as expected 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 temp stratic.io domain by default, but you can connect a custom domain if you have one.
Change the site to WordPress
You can install WordPress in your Strattic environment by clicking on Editing in WordPress button in the sidebar of the home page.
This will start WordPress and redirect you to the typical WordPress setup workflow.
Go through the steps and provide the information requested in each step. You will then be asked to log in to the admin dashboard. There you can create posts and pages, install plugins and themes, and manage your website just like you would in a vanilla WordPress setup.
Benefits of using headless WordPress
Traditional WordPress is preferred by non-technical users as it does not require any coding knowledge. But for experienced developers who want more freedom and a better development experience, WordPress may fall short.
If you are one of those developers, you might consider decoupling WordPress from the front end. Let us examine some of its main advantages.
It supports multiple tools, frameworks and libraries
With vanilla WordPress, you are forced to stick with technologies built into the stack. This architecture prevents you from integrating tools and libraries in which you may have more experience.
In contrast, headless WordPress is technology agnostic, so it can integrate with a larger 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 held in a database, they load slower than a static website created using HTML files. When plugins are included in the equation, the website gets even slower.
As you know, headless WordPress works by pre-generating HTML and caching it in CDN servers around the world. This setup greatly improves the speed at which your site is delivered. Additionally, you can integrate your backend with a Next.js or Gatsby frontend to enjoy performance benefits like server-side rendering and out-of-the-box SEO options.
Better security
Vanilla WordPress is a huge playground for hackers. In fact, hackers can perform brute force attacks or overload your website with DDoS attacks just by logging into your website /wp-login.php file.
On the other hand, a site with a headless architecture is not susceptible to this type of attack. WordPress is no longer used for data output, so the same vulnerabilities that plague WordPress cannot be applied.
Additionally, the API-first setup of headless WordPress allows you to add cybersecurity services and tools to fend off any other form of attack.
Conclusion
With the headless approach, you get huge gains in performance and architectural freedom. On the flip side, you are faced with complexities that may be too much to handle if you are a novice developer or non-tech person.
Headless WordPress will in no way replace traditional WordPress. It’s more of an option for companies with a necessary team of developers who want to scale their platform or service to new server use cases.
Go headless if you have what it takes. Make sure you’re doing it for the right reasons before you commit. You will not regret.
