As with all technological choices, deciding on what powers your website centers on the right trade offs. Headless CMSs, single page applications and static site generators have been around for a while now in the web development world. But, when is the right time to utilize these tools? In many enterprises choices are frequently made without considering all the technical implications of the final implementation and often left opaque for many marketing stakeholders in what’s typically a development/IT endeavour. This thought piece is an attempt to get a high level view at those choices from a perspective of a digital marketing agency that’s been asked this question fairly frequently.
While applications for the headless CMS are many, let’s focus on a particular use case of this technology, the company website. To frame the discussion further, lets consider a few common needs digital marketing has in terms of a managing a company website:
A headless CMS is part of an architecture pattern that emerged recently as an answer to specific problems companies with a large digital presence had. It aims to decouple the responsibilities of maintaining content and displaying it, mainly because in the landscape of numerous platforms and mobile applications that were displaying the content, it wasn’t feasible to keep duplicating the effort of rebuilding content management interfaces or pass around content in word docs.
Create human-centric digital experiences that delight users and produce business insights.Learn More →
Convertiv engineered a solution that could power customer engagement and transform a sprawling organic platform into a lean, intuitive, and performant tool.View customer story →
Centralizing content governance makes a lot of sense from both a process and a technological perspective. It prevents user errors, promotes polyglotism (the ability for different technical teams to employ different coding languages and tools to solve their challenges), separates concerns and increases security.
One of the most frequent implementations of a headless CMS in the enterprise revolves around using SaaS vendors such as ContentFull, Content Stack, Prismic etc. These vendors employ a subscription model and in turn provide the software and support for a certain volume of requests to the content. These CMSes provide most basic features you would expect from a enterprise CMS like fine grained access control, localization support, scalability and high availability and even things like media management with CDNs.
Some of the products in this category do specialize in certain types of content or scenarios but everything you need to define a content structure, operationalize a workflow and make the content available via neat REST APIs is there, and then some.
The headless CMS is just a piece of the puzzle that makes a certain architecture possible, a centralized and governed content repository servicing many consuming frontends that display that content. Looking at the headless CMS technology in isolation it makes a lot of sense and it certainly addresses some pain points with traditional approaches. To fully understand the business impacts of this approach though, its necessary to look at the whole technical solution which includes the content consuming side – a website frontend. The decoupled nature of this approach opens a plethora of choices when it comes to building the website frontend and its easy to make the wrong trade offs.
The reactive paradigm of building web applications that got popularized by FaceBook and their React library made creating single page and mobile applications much more streamlined and maintainable. It solves various problems of building a web application that requires displaying rapidly changing content. Said content is susceptible to change by either direct user interaction or some sort of backend update; think online chats, message boards and erm, FaceBook.
Predating React, Angular is a web framework made by Google that addresses many pain points of building complex single page applications on the web. One of its main features includes two way data bindings that allows for elegantly writing highly interactive apps.
Good websites put a lot of effort into polishing the UX, making sure that visitors can quickly and easily navigate and find what they need and successfully convert. While the above frameworks and their clientside nature supports that effort in various ways, a lot of times it fails to do the same for the search engine crawlers, thus leaving a lot to be desired in terms of their SEO value. A good website is really only good if somebody can easily find it.
Creating new landing pages, releasing new products or crafting new sections for the company website are a frequent task for Marketing departments and teams belonging to that purview. For a good marketing operation, its important that these tasks are efficient and happen with as little friction as possible.
Because the building blocks of a headless CMS powered website are more generic and non-specialized, they often lack basic features of websites and content management: metadata, user-editable menus, blog sections and post indexes, RSS feeds, site search, editable URLs for pages, protected pages, content previews and scheduled publishing etc. Reduced complexity is great and beneficial for many software projects, but when its faced with day to day website management, its often a debilitating to find out a basic feature hasn’t initially been scoped for and needs to be built first.
Building things from the ground up allows for more control of end result, but it also bears a greater risk of broken implementation. Having a large and capable development team with many specializations and dedicated QA makes that possible but the feasibility is a very personal question for most organizations.
In a lot of cases, even smaller content updates and modifications end up asking for developer time, creating a bottleneck that slows down any digital marketing efforts.
Workarounds like that do inevitably create complexity in software, have drawbacks and caveats and should be carefully weighted out. The more complex the project becomes, more resources it consumes – requiring more developers, more time and more effort.
To be perfectly clear, its not that these approaches don’t have their applications, far from it – it would not be possible to build some aspects of the modern web if it weren’t for these technologies. If your company website is your primary business and you have the resources to pursue advanced web architectures for all the right reasons like performance, scale, and security, the extra complexity is a good trade off.
While discussing the topic of headless CMSes, its worthwhile saying that the more traditional players in the CMS segment these days all fit perfectly into this architecture pattern and are able to work headless. Well represented open source systems like WordPress or Drupal both expose a rich set of content APIs that can be used to siphon off content to wherever it needs: powering your email marketing, multiple native or web applications or statically generated websites. A system like WordPress, holding a 30% market share of all websites out there, benefits from having a polished content management experience that most people are already familiar with. Given this flexibility, its also possible to start with a regular CMS powered website and grow into leveraging specialized frontends by going headless later if you identify specific reasons to do so.
Various headless CMS architectures and approaches have a lot of applications across industries but to cope with the underlying complexities they require resources and dedication usually available in large enterprises.