You're viewing help content for version:


Although the Single-Page Application (SPA) Editor is available as part of the We.Retail Journal sample content (requires AEM 6.4 service pack 2), its server side rendering features as described in this document are still considered a technical preview, available for testing and feedback but not intended for production roll out.


Single page applications (SPAs) can offer the user a rich, dynamic experience that reacts and behaves in familiar ways, often just like a native application. This is achieved by relying on the client to load the content up front and then do the heavy lifting of handling user interaction and thus minimizing the amount of communication needed between the client and the server, making the app more reactive.

However this can lead to longer initial load times, especially if the SPA is large and rich in its content. In order to optimize load times, some of the content can be rendered server-side. Using server side rendering (SSR) can accelerate the initial load of the page and then pass further rendering on to the client.

AEM-Driven Communication Flow

When using SSR, the component interaction workflow of SPAs in AEM includes a phase in which the initial content of the app is generated on a Node.js server.

  1. The browser requests the SSR content from AEM

  2. AEM posts the model to the Node.js server

  3. The Node.js server returns the generated content

  4. AEM serves the HTML returned by the Node.js server via the HTL template of the backend page component.


Node.js-Driven Communication Flow

The previous section describes the standard and recommended implementation of server side rendering with regards to SPAs in AEM, where AEM performs the bootstrapping and serving of content.

Alternatively, SSR can be implemented so that the Node.js server is responsible for the bootstrapping, effectively reversing the communication flow.

Both models are valid and supported by AEM. However, one should consider the advantages and disadvantages of each before implementing a particular model.

Bootstrapping Advantages Disadvantages
via AEM
  • AEM manages injecting libraries where needed
  • Resources only need to be maintained on AEM
  • Possibly unfamiliar to SPA developer
via Node.js
  • More familiar to SPA developers
  • Clientlib resources required by the application such as CSS and JavaScript will need to be made available by the AEM developer via the allowProxy property
  • Resources must be synched between AEM and the Node.js server
  • To enable authoring of the SPA, a proxy server for the Node.js instance may be necessary

Planning for SSR

Generally only part of an application needs to be rendered server side. The common example is the content that will be displayed above the fold on the initial load of the page is rendered server side. This saves time by delivering to the client, already rendered content. As the user interacts with the SPA, the additional content is rendered by the client.

As you consider implementing server side rendering for your SPA, you need to review for what parts of the app it will be necessary.

Developing an SPA using SSR

SPA components could be rendered by the client (in the browser) or server side. When rendered server side, browser properties such as window size and location are not present. Therefore SPA components should be isomorphic, making no assumption about where they will be rendered.

To leverage SSR, you will need to deploy your code in AEM as well as on a Node.js server. Node.js is responsible for the server side rendering. Most of the code will be the same, however server-specific tasks will differ.

SSR for SPAs in AEM

SSR for SPAs in AEM require a Node.js server, which is called for the rendering of the app content server side. Within the HTL of the app, a resource on the Node.js server is called to render the content.

Just as AEM supports the Angular and React SPA frameworks out-of-the box, server side rendering is also supported for Angular and React apps. See the NPM documentation for both frameworks for further details.

For a simplistic example, please refer to the We.Retail Journal app. It renders the entire application server side. Although this is not a real-world example, it does illustrate what is needed to implement SSR.


Adobe recommends a separate Node.js instance for every AEM environment (author, publish, stage, etc.).


This document uses the We.Retail Journal app for demonstration purposes only. It should not be used for any project work.

All SPA projects on AEM should be based on the Maven Archetype for SPA Starter Kit.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy