Wordpress released in 2003, and this was a huge leap forward in the democratization of the web. Wordpress was easy to use, and had multiple ready made templates to help you express your brand better. ‘Hosted Wordpress’ solutions ensured that even non technical users were able to manage their own content online.
And this shows: Wordpress still powers about 30% of the internet.
This was primarily due to three factors:
The traditional CMS coupled the presentation and content very tightly. This meant that it was difficult to drastically change the behavior, or even the look and feel of your site without writing code for your CMS. Adding new widgets and collections of articles became tedious. Many CMSes tried to address this issue by providing a library of plugins. However, as the number of plugins installed increased, the amount of IT staff to manage it also grew. Further, many plugins would often conflict with each other, requiring further IT staff to manage.
The number of formats on the web have increased drastically. While home pages were the primary entry point to your content (with RSS thrown in for good measure), today’s readers consume your content via Facebook Instant Articles, Google AMP, Mobile Apps, 3rd Party Syndication and dozens of other channels. You need to store your content in a way that adapts to all of these (as opposed to raw HTML).
Tech teams have started to specialize. The average publisher receives traffic on a scale that was unimaginable in 2003. And the skills required to manage security, data loading, and caching, are often quite different from the skills required to build a stunning visual front end. And it's more likely that your business’ differentiators are the latter.
A Headless CMS removes the presentation layer from your CMS. Instead, your CMS only manages content, and outputs this content via APIs, allowing you to build multiple consumer channels, including your website. This technique is known as Content as a Service, and solves multiple of the above problems.
The concept of plugins goes away. Plugins were typically intended for front end concerns, and these can be implemented directly in your front end app, without any customization of the CMS itself.
Omnichannel by default. Since every channel communicates with the same set of APIs, every channel becomes a first class citizen. Adding a new channel is as easy as building a simple adapter, and a good CMS will come with multiple adapters out of the box.
Code Once, Consume everywhere. Let’s say that multiple channels use a particular API for getting recommendations. Updating the logic behind that API means that all consumer channels will get the new algorithm, without any code change.
You can hire the team that you like, focussing more on a team that will build out your unique front end.
Securing the CMS is a much easier effort as it is not on the same domain as your readers. Further, the lack of plugins and presentation logic on the backend means that your security vector is smaller.
Finer control over scaling and caching. This helps ensure that you spend your infrastructure budget wherever it gives the most value. Splitting what was earlier a massive page load into multiple smaller API calls allows you to define Caching and Scalability requirements individually.
Even better, keeping a standard set of APIs opens the possibility to outsource your CMS, drastically reducing your IT costs.
Quintype uses all of these benefits by providing your CMS as a service. We manage your entire publishing stack, from infra and maintenance, to recommendations around SEO. Thanks to the decoupled nature of our CMS, we find that our publishers are able to go live with a gorgeous, offline first version of their sites in a matter of days, where it earlier took months.