Back in 2023, I wrote a blog post titled “Headful or Headless AEM? Why Not Both with Hybrid?” to highlight the benefits of a Hybrid AEM approach amid an increasing need for multi-channel content. I noted that Headful AEM provided many benefits, including WYSIWYG authoring, decoupled code/content releases, and keeping authoring in one platform.
A lot has changed since then, including the introduction of Adobe’s Edge Delivery Services (EDS) and Universal Editor (UE). Before I jump into what’s new, let’s review why some teams are looking to go headless after many years of headful experiences.
- They need content creation and management shared by multiple downstream apps. This is often referred to as multi-channel content.
- Traditionally, this has been supported by Adobe’s Content Fragment technology.
- The engineering teams want declarative components (SPA-like experiences) rendered server-side.
- AEM does not yet have native support for server-side rendered declarative component frameworks like Next.js. Today, Edge Delivery Services and traditional component development both utilize imperative components. We’ll have to wait and see if this changes in the future.
- The engineering teams do not have as much AEM development experience as with their preferred stack.
- This can pose a risk to cost and time-to-market. However, moving headless introduces custom implementation work such as cache refresh, authentication, content retrieval integration, and content route mapping that may lengthen the timeline regardless.
Headful
If you do not have any of the above headless requirements and no existing AEM components, I recommend Adobe’s latest “Headful” solution utilizing Edge Delivery Services to render static HTML + CSS + JS at the edge of the network. The rendered pages are very fast with strong Core Web Vitals scores. Teams typically need only light training to implement the authoring instrumentation, so I would recommend it even to teams without traditional AEM development experience.
If you have existing AEM componentry, AEM as a Cloud Service with traditional component development is still supported. A Hybrid AEM approach remains an excellent way to build Headless integrations on top of existing Headful implementations.
However, for new sites or redesigns, Edge Delivery Services is a clear winner.
Headful Recommendation: Edge Delivery Services for New Implementations
Headless / Hybrid
In 2026, Headless is a much stronger contender than it was just a few years ago. You no longer need a Hybrid architecture to retain WYSIWYG, in-context authoring. Adobe has introduced the Universal Editor, a powerful tool to author AEM content directly on top of a downstream web application.
In a headless model, authors create Content Fragments in AEM, expose them through GraphQL APIs, and downstream applications retrieve and render that content. Universal Editor adds the capability to open a downstream page that contains those fragments. If the page is instrumented for authoring, authors can add, delete, and edit Content Fragments directly in the context of the rendered application. They no longer need to swap back and forth to view the changes.
This gives engineering teams the freedom to use their preferred technology stack, while still providing authors with the speed and familiarity of AEM’s in-context editing experience.
Headless Recommendation: Universal Editor
Now, what you might notice about headless requirements 2 and 3 is that these are not content-driven requirements. These requirements are driven more by technology and team preference. Why is that important? Well, content fragments were primarily designed to solve a multi-channel use case. They’re not inherently attached to any page, which creates content management challenges.
- How does an author track usage of those content fragments downstream from the CMS? This often requires a custom solution like beacon analytics.
- Useful AEM tooling like Multi-site Management, Page moves, Metadata authoring, and Page Publish Workflows are not available out of the box for Content Fragments.
- Link checker no longer functions because AEM does not have any inherent knowledge of the downstream routes.
- Downstream applications pull in fragments by name or by query. This creates a process where CMS authors must adhere to a “mapping pattern.” This involves either a strict content fragment naming standard or a uniquely generated name field that is consumed programmatically downstream.
- If it’s a generated name, this creates a strict author-to-developer handoff process for new pages or content sections.
- For example, if the downstream application wants to pull a particular component for the home page, what path or name does it look for the fragment in the CMS?
- Existing AEM authors are typically more experienced with creating and managing pages instead of content fragments.
- It creates a platform disconnect. Authors must navigate to AEM to create Content Fragments, but navigate to the downstream application or the Universal Editor to view changes in context.
But Wait, There’s Good News!
We don’t have to use content fragments alone or at all. The Universal Editor also supports writebacks to AEM page-based resources. This solves many of the experience challenges we have with headless implementations. We can learn from the architectural patterns of an AEM Hybrid implementation and apply them in detail next week.
For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others). Contact Perficient to start your journey.
