Skip Main Navigation

When to use single-page applications

These days, many of our clients are asking for modern frontends – in particular for websites that use single-page application (SPA) frameworks. SPA websites have been around for awhile, but they’re experiencing a resurgence in popularity as the gold standard of website creation (think of Spotify or Netflix). The most popular libraries are React, Angular, and Vue, and they all support the development of single-page applications, making SPAs all the more relevant today. SPAs seem to be a widespread solution for today’s frontend needs – but what needs do they solve for exactly and how do they compare to other approaches? 

 

Before we dive into the specifics of SPAs, let’s recap how they emerged into the web development scene. Following the proliferation of asynchronous JavaScript and XML development (AJAX) in the 2000s, SPA frameworks were the next logical step. They’re able to refresh individual components or fragments of a DOM instead of reloading the whole page as HTTP protocols typically do, which makes them a much more efficient solution in cases with highly dynamic UIs. SPAs provide powerful state management and other helpful features which enable developers to deliver fast, native-like applications with smooth page transitions and modern UX. Gmail, Google’s email web app, is one of the most well-known examples of SPA implementations out there. 

 

But of course, SPAs are not magical, one-size-fits-all solutions. There are several factors that can affect speed, and determine whether SPAs are right for a use case. Let’s unpack some of these considerations.

UX

User experience is critical in the consideration of any tech build. We should always start with the user journey – their motivations and the paths they’re taking through the ecosystem – to decide what sort of architecture and tools makes the most sense. 

 

To achieve buttery smooth page transitions with content, widgets, components and everything else your page requires, you need a lot of JavaScript. Even if we lazy load optional files on the initial page load, this huge amount of JavaScript comes at a cost. The code has to be downloaded and parsed by the browser, the execution takes time, and may not deliver the level of experience your business aims for. Plus, if we’re using a mobile-first approach, we can’t assume that we have fast connections or powerful computers at our disposal. 

 

The browser’s page history is another aspect in the UX that should be considered. The built-in history allows you to navigate back and forth between visited pages. SPAs effectively re-engineer this feature, as state management happens within the application hidden from the browser. You’ve probably encountered this in web apps that break when you try to use the regular back button. This is a critical UX issue that requires some additional consideration to be implemented correctly.

The need for speed

The truth is, SPAs are not faster than regular server-side rendered HTML pages, at least not on initial page load. Using JavaScript to create HTML on the users device has a performance cost, and it seems that web developers are starting to come around to this. 

 

We have seen many SPA applications with server-side rendering capabilities. This is great, but it seems like they’re trying to address a problem that didn’t exist in the first place. Sure, having server-rendered HTML cached on a content delivery network (CDN) near your users with appropriate response headers is fast, but this has been the norm for over a decade. Maybe it was with less capable CDNs spread across the world, but HTML has always been the cornerstone of delivering content. Using client-side JavaScript to create static, not user-specific HTML will always be slower than directly rendering and caching the HTML server-side. 

 

We also need to differentiate between initial page loads and subsequent page changes. After a SPA has been fully loaded into the client browser, loading a second state may be faster than a regular page change. In the end, SPAs just load whatever they need to and refresh the UI; so the payload is smaller, but HTML rendering comes on top. We should always consider what the user journey actually calls for. If your site is usually accessed via deep links and the user doesn’t usually visit multiple pages, it doesn’t make sense to slow down the first-page load to make subsequent loads faster. It’s best to make data-driven decisions and test along the way to find the right solution for your use cases.

AEM Integration

There are many options to integrate a SPA with AEM. The question comes down to how we combine the application and presentation logic from the SPA with the content from AEM. AEM is highly flexible and can support most use cases. Whether it makes more sense to keep the application logic in the browser within a SPA or server-side in AEM, you should consider specific use cases and set up a well-rounded architecture. 

 

These are some of the most common setups, according to the combinations of requirements: 

  • SPAs with AEM serving content completely headless as JSON (aka Content Fragments)
  • SPAs with AEM serving content as snippets of HTML (aka Experience Fragments)
  • SPA that only cover parts of the page, embedded into server-side rendered HTML coming from AEM 
  • Using the AEM SPA Editor to seamlessly edit content through the AEM Authoring Editor
  • Using Commerce React Core Components to setup shopping scenarios on page

 

These setups aren’t mutually exclusive, either. They can be hand-picked and even combined for individual use cases. Everything depends on what you require. Ask yourself: what’s our plan for maintaining the code and content? What role does the content play? For example, do we need a what-you-see-is-what-you-get editor? How much influence over layout do authors need on a regular basis? The answers to these questions will determine what kind of architecture will serve your scenario best. 

SEO

Another decision driver is search engine optimization (SEO). If SEO plays a major role in your business model, you need to consider a few things. Even though Google is theoretically capable of indexing SPAs and pages built with client-side JavaScript, serving HTML directly from the server will always be easier and quicker for computers to understand. One option is to combine additional server-side rendering to your SPA with frameworks like next.js. If SEO is top priority for your business, you may even want to steer clear of SPAs entirely.

Think about your case

As with making any kind of architectural decision, whether or not SPAs are right for you will depend on your particular goals and context. While we’re fans of adopting new technology and frameworks, we will always be stronger advocates for keeping it simple, rather than jumping into needlessly complex architectural setups. 

 

Here are some good questions to ask to guide your team to a sound decision: 

  • How is your application used? By whom? 
  • How modern is your IT landscape? Is it service-oriented? 
  • How do you ensure the quality of development, maintenance, and support? 
  • How user-specific is your content? 
  • How much do users interact with the content or transition between blocks of content? 
  • How important is SEO to your business? 
  • What are your key performance metrics? (i.e. initial bootstrap time, follow-up content reload speed) 


Talk to one of our experts today – we’ll be happy to help you hone in on the solution that best supports your users and business goals.


Andreas Haller

Principal Solution Architect


Ricard Torres

Senior Frontend Software Engineer

More Developer Circle