Our Approach to Headless Architecture
When building a website, the choice of platform to build upon is multifaceted. Traditionally, a platform supplied the visual display of content to end users as well as the editing and management of that content. However, a different approach is becoming more popular and is worth considering for most public-facing sites. This headless approach separates content management from the display of that content, allowing each tool to be optimized, creating a more performant, secure, and flexible result.
Advantages to Using a Headless Architecture
Content Delivery
The biggest advantage of a headless approach to content management is that the content store can start to serve more than just a website, creating multi-channel opportunities (e.g. marketing professionals can manage the content for the website, the app, and a voice assistant in one centralized repository). When needed, this enables a huge multiplier in productivity.
Enhanced Performance & Scalability
When the front-end of the website doesn’t have to deal with content management, it can be dramatically simplified. Often the architecture ends up being totally or mostly static, able to be hosted at extremely low costs with extremely high up-time and reliability. This also produces CDN-friendly results, which can be used to significantly increase performance even more.
Security
When the public-facing site can be static, there’s almost no attack surface to defend against hackers. And it’s easier to lock down the CMS when its configuration doesn’t need to also apply to public viewers.
Flexibility/Customization
Frameworks for displaying content, like Astro, tend to be very flexible, allowing designers to achieve any vision. Gone are the days of being locked into inflexible templates and displays that cannot be customized.
When to Use a Headless Architecture
At Engage, headless is our default choice when there are no other technical constraints, like a pre-existing CMS or tech stack. We’ve been loving using Astro for building a static (or mostly static) frontend, and have started trying out Payload CMS to host the content management.
When It’s The Right Approach
- Where performance is important (which is most sites)
- Where security needs to be strong
- Where cost-savings is a driver
When It’s Not The Right Approach
- Pre-built extensions may be fewer (but maybe not)
- Deep integration between the CMS and the display may be nice sometimes (but newer CMS options have extensibility points to provide many of these integrations)
- For highly interactive experiences, where end users are regularly editing content in addition to viewing it, a headless architecture may not have as many benefits