Part one of this series explained how traditional content management systems work. In summary, they assemble a site page from various parts on the fly with every page load. This requires dozens of requests to the server, while a headless CMS loads a pre-baked web page (to understand why, read Part one). But so what? In today’s post, I explain how this affects performance, security, reliability, and scalability.
For every extra second it takes your site to load, conversion rates drop by an average of 4.42% (Portent, 2019).
If you read part 1 of this series, you know how monolithic CMS works, and you can imagine how much slower it is to build each web page on the fly. No matter how many tricks you use to speed up your site, loading the page still requires the server to make dozens of automated requests to pull in your text and images from the database. Compare that to a hand-coded HTML website, with all the data contained in one server request. Such a site can load in half a second.
With a headless content management system, your site can still be dynamic, but all of these updates are compiled automatically into a fully rendered page that loads shockingly fast.
Knowing that a conventional CMS sends dozens of requests to the server, consider who, or what, is making those requests. To expand the default features of the content management system, companies rely on dozens of plugins for things like social media buttons, lead gen forms, contact forms, etc. Each of these applications must have access to the content database.
The architecture is set up differently in a headless CMS. There’s only one endpoint to access your data, exposing fewer attack surfaces to bad actors. When your team wants to use external martech, they can connect securely, such as behind a VPN.
Additionally, a conventional, monolithic CMS is vulnerable to DDOS attacks. In a DDOS attack, hackers make so many requests to the server that the web host is too overwhelmed to respond to any of them. Even just downloading the title of the page from the database takes too long, and the server hosting the files gives up. Do you see where I’m headed with this (pun intended? Always!)?
If your headless setup serves a single HTML page, that is one request from the server. The same site built with a monolithic CMS that makes 40 server requests would arguably be forty times easier to take down with a DDOS attack.
Just like with a DDOS attack, a monolithic CMS is more vulnerable to the hug of death. If one of your articles goes viral, you’ll have a sudden burst in traffic. All of those users simultaneously accessing the website could overwhelm the server. New leads flowing to your site end up competing for bandwidth, making the site slower than ever, just when you need it to be at its best! Eventually, a company will need to pay more for hosting to accommodate increases in bandwidth required for all of these server requests. Just like with a DDOS attack, the site could shut down entirely.
In contrast, a headless content management system pre-bakes the content into an HTML page before it is published to a website (again see part I of this series to understand the technical details of why this is so). The web browser only needs to download the content for a simple HTML page. Content is assembled before it is published to your website, so your pages load fast, even with big bursts in traffic.
Consider two pizza places, one is like conventional CMS: You order a pizza, and the Flash comes out and bakes the pizza right there in front of you. It only takes 5-10 seconds because he’s the Flash!
At the headless pizza joint, you order the pizza, and it instantly appears on your plate because it was baked before it got to you. All the Flash had to do was serve it to your table.
The headless pizza is assembled differently (with API calls instead of a PHP script querying MySQL DB), but the important thing to understand is that however it is assembled, it is pre-baked. If you go to the web host for our headless pages, you will see regular HTML pages. Whatever made them, or has the power to update them, does so behind the scenes.
Whereas, if you go to a WordPress site, you will still see an HTML page on the front end but in your site files in the web host/server you will have this:
It’s just a bunch of folders and some PHP scripts. Note there are no HTML pages on the server. Each of those folders has 5-20 folders, even if the entire website is only one page. That’s because on your website, there is no HTML page. Instead, visiting the page triggers a script to build the HTML page for the visitor.
There’s nothing special about the way headless does it. If your site is only one page, headless will have a single page of HTML. The way monolithic does it is the weird way. It’s weird to run a script with all those folders to display web content. A bit of overkill! But it happens so quickly it seems like a regular web page.
Many small companies function just fine on a monolithic content management system. Until they grow. Yes, as your site gets more popular, the problems with page load speed compound. And those scaling issues happen at the front end and the back end.
Imagine your company sells gremlins to old-timey knickknack shops. At first, the only plugins you need are an ecommerce plugin and a discussion forum where your customers can debate proper gremlin care and feeding.
Over time, gremlins become the hot holiday gift, and your little startup is now an enterprise. You add plugins for better security, analytics, and A/B testing. None are perfect, but you have to make do with what works with your CMS.
All these plugins make the site huge and complex, and (what with all the havoc your gremlins are wreaking) the discussion forum is even bigger. The new AI chatbot causes a bug in the discussion forum. The website becomes a patchwork of add-ons to a legacy CMS that was never intended to be modular. Each plugin requires numerous server requests, slowing your site. Now your company has a problem. Do you want a fast site, or do you want all these features? But before you answer, it gets worse!
Demand for gremlins goes global. You duplicate your site into five languages. Aside from the SEO issues this creates, you’re making five different versions of every piece of content. Meanwhile, the product team decides to launch an app for gremlin tracking and retrieval. You’re also creating content for the new call center you set up to handle complaints when gremlins tear up the town. When updating the “Gremlins on a Plane” product description, the team must remember to change all five websites, the call center knowledge base, product content on the discussion forum, and the app. They require a complex system to keep track of it all. Your site is now an even bigger mess than a pub full of gremlins.
This is where a headless CMS really shines. You have more flexibility in the services you use for these additional features because you’re not limited to plugins for your CMS. Staff can use a VPN to access customer data securely. The user membership area can be tackled with a customer data platform. Everything is modular from the get-go.
Within your headless CMS, the content is the focus. If your marketing team decides mogwais are more marketable than gremlins, you can update the content in your headless CMS and have it automatically pushed out to your five websites and your app.
This ability to push content out to a variety of channels is a big part of why so many companies are going headless. But not every company needs an omnichannel approach. The author of a children’s book isn’t likely to need a headless CMS, even as her publisher is making the switch. Headless CMS have some challenges, such as gathering traffic data on content.
Still unsure if headless is right for you? In my previous post I detail the factors in your company that suggest it is time to consider going headless.
Checkout part one and two of this three-part series:
Ready to take the plunge? Check out our headless content management system tour.
Karma has over a decade of experience with content marketing and SEO. In addition to marketing, she writes about tech, music, and politics. You may find her shamelessly singing along with the muzak at the grocery store or giving marketing advice at KarmaBennett.com.