Building Lightning-Fast Websites With AEM’s Hybrid Headless Architecture

Composable is becoming a game-changer in the software architecture paradigm, built on a foundation of  microservices-based, API-first, cloud-native, and headless technologies.  A key benefit that entices organizations into adopting composability is the promise of increased PageSpeed scores and the customer experience benefits that come with it.

Adobe Experience Manager has underlined its shifting focus towards composability by incorporating features such as the Universal Editor, Project Franklin, and GraphQL under its umbrella.

In this article, we will demonstrate how to leverage a Hybrid Headless architecture to build lightning-fast, high-performance websites using the AEM Remote SPA option to achieve a Hybrid Headless pattern.

Headless on AEM

AEM has evolved over the years to become a powerful Hybrid Headless CMS.

If you started with AEM a couple of years ago, you probably didn't choose it for its headless capabilities but for its powerful Headful features. On the other hand, if your focus is entirely on a "headless" architecture, perhaps AEM is too robust for your needs, and you should consider exploring something lighter. In this context, adopting a Hybrid Architecture is often a wiser choice in most scenarios.

Why AEM SPA Editor?

The SPA remote is our choice to combine the best of both worlds: Headless functionality without sacrificing the WYSIWYG experience. This is the option you should consider if you aim to achieve a "Hybrid" architecture without abandoning your Headful content, positioning yourself well for an omnichannel approach.

But there's more. Let's consider some lesser-known facts about working with the SPA Editor:

• The "SPA Editor" is designed for Single Page Applications (SPAs), but is this a disadvantage? Technically, no limitation prevents you from building a multi-region/multi-language site, but that wasn't the original purpose.

• While SPA Editor components can leverage any front-end framework, Adobe officially supports only Angular and React.

• Another important point is the need to separate concerns, although sometimes there can be gray areas when working with SPAs. For example, consider the AEM SDK. Is it primarily intended for the AEM developer, the front-end developer, or both?

• When choosing the AEM SPA Editor, more critical decisions must be made upfront. For instance, where you host the app can be vital for developers, requiring consideration of factors such as CORS and caching. Another example is the potential use of Server Side Rendering, among other things.

• Currently, we are using AEM SPA Editor v2, which offers the following advantages:

  1. Full access to layout and state control.

  2. The SPA can be hosted either inside or outside AEM.

  3. It enables in-context editing for smaller, specific sections.

  4. The application ("head") should drive the content.

• The AEM SPA Remote components for Next.js may have certain limitations. While they offer a solid starting point, they are not necessarily ready for deployment out-of-the-box.

Why Next.js?

The answer is simple: it is a framework that facilitates achieving web performance and web optimization. Here are some of the highlights:

• It supports image optimization, managing aspects like laziness, format, size optimization, and security.

• It supports a hybrid approach between Server Side Rendering (SSR), Static Site Generation (SSG), and Client Side Rendering (CSR).

• It offers Incremental Static Regeneration (ISR).

• It is a well-known and trustworthy framework built on top of React, with a large community constantly providing support.

Building a Proof of Concept: Evaluating AEM and Next.js

Launching a Hybrid Headless Architecture using AEM SPA Editor can increase mobile PageSpeed performance by up to ~30% when combined with Remote components designed for Next.js. To illustrate this, we conducted a Proof of Concept (POC) assessment to determine the ease of building high-performance websites using these technologies.

Goal of Proof of Concept Study

The objective is to assess the feasibility of creating high-performance webpages and to gauge how straightforward it is to leverage the latest technologies offered by Next.js. For the Proof of Concept (POC), we will reconstruct two pages from the WKND site, Adobe's official demo site for AEM Sites. The chosen pages will include the About page and one of the Article pages.

To measure performance, we will rely on Google PageSpeed Insights and Core Web Vitals scores, focusing on the performance indicators that assess aspects such as First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and more.

Disclaimer

While we will replicate the WKND pages, please note that these will primarily mimic the user interface (UI) and may not necessarily align with the backend functionality. However, it's important to emphasize that all components will be authorable, ensuring the final result remains fully customizable by content authors.

Next.js Remote SPA Details

Here are some noteworthy details:

• The application was developed using Next.js version 13.2.0 and Node version 20.2.0.

• The application was constructed using the AEM Next.js Template provided by Adobe.

• The application was deployed on Vercel through GitHub actions, following Vercel's recommended approach.

• The "WKND About" page utilizes Server Side Rendering (SSR).

• The "WKND Article" page employs Static Site Generation (SSG).

• Content is sourced from AEM on-premise version 6.5.16.

• The AEM content is accessed via the dispatcher.

Results

Following is a before and after comparison between both WKND pages.

Page #1: WKND About Page

The Mobile PageSpeed performance increased by approximately 20%.

The Desktop PageSpeed performance achieved a score of 100%.

Page #2: WKND Article Page: Western Australia

The Mobile PageSpeed performance increased by approximately 30%.

The Desktop PageSpeed performance achieved a score of 100%.

Conclusions

The key lessons learned during this Proof of Concept (POC):

• Creating performant and fast pages using Next.js as a front-end framework was straightforward. Many optimizations, such as lazy loading images, size and format optimization, font preloading, etc., were readily available in Next.js. Therefore, having experience with the framework is essential to leverage this architecture fully.

• The AEM Next.js template had some issues that needed to be addressed. It may not be ready for production use out-of-the-box, but serves as an excellent starting point.

• The AEM Next.js template officially supports Next.js 12. Upgrading to Next.js 13 is possible, but there are trade-offs to consider. You can either stick with Next.js 12 for official support or risk using Next.js 13 to benefit from its latest features. For this exercise, we decided to go with Next.js 13.

• The AEM React Components worked well and provided a reference for developing new Next.js components since the technical foundation is essentially the same.

• We had to add several AEM SPA NextJS components that use the Sling Model Exporter and map them to Next.js using the AEM SDK. This is the traditional approach if you are accustomed to creating SPA React or SPA Angular projects. However, mapping components like "Container" and "Tabs" can be tricky due to a lack of experience working with the AEM SDK.

• Using Static Site Generation (SSG) significantly improved the performance of the testing page. However, it also introduced complexity in maintaining consistency when changes are applied. Fortunately, Next.js offers the "Incremental Site Generator" feature to automatically invalidate pages and keep content fresh. This is a good option for real-world projects, but we had to create a manual way to invalidate pages for our specific scenario.

• Using Server Side Rendering (SSR) also appeared to be a good option, as it enhanced the performance of the testing page.

• Introducing SSG also introduced another cache layer, which requires proper cache strategy management.

Final Thoughts

Adobe Experience Manager introduces the AEM SPA Editor feature to enable developers to build a true Hybrid Headless architecture. While it's not a one-size-fits-all solution, it offers flexibility that should be considered on a case-by-case basis.

Embracing this architecture opens up the opportunity to fully utilize Next.js, which is renowned for its exceptional features. As we move closer to adopting a Headless Architecture, we align ourselves with the principles of composability—an essential aspect of our pursuit.

Learn more about headless AEM by reading: What is Headless AEM?