Reduce Abandon Rates with the SPA Treatment

Introduction

Single-page applications (SPAs) have become the name of the game in modern web pages. Users expect to receive a web page instantly and are no longer used to allowing loading spinners to whirl away while large unseen portions of the page are loaded. One study showed that 53% of mobile users will abandon a site if it takes more than 3 seconds to load. Consider that half of all Internet traffic is now coming from mobile devices, which can encounter an array of scenarios resulting in lackluster connectivity, and the importance of performance is all too clear on the modern web. Downloads of the most popular SPA frameworks via NPM, the JavaScript package manager, have more than doubled yearly since they started being offered and it’s not hard to see why. So, what exactly are single-page apps? What are their advantages and when should you use them? Once you know you want to give SPAs a go, how do you go about fitting them into your engineering structure? This post will explore these topics.

What is a Single-page Application?

A SPA is a single user experience that happens without loading another page from a server. The URL may or may not change, which we’ll discuss more later, but all interaction occurs without the user “leaving” the page. Compare this to traditional site navigation – now commonly referred to as Multiple page applications (MPAs) – where the navigation from one page to the next occurs with a page reload. We typically refer to the “back-end” as the processing that happens on a server, while the “front-end” is the part of the application that exists in the user’s browser. The emergence of robust back-end programming languages, such as Python, helped drive websites from being largely static pages to offering customized and more engaging content driven by robust back-end frameworks and easier development paradigms. As back-end frameworks became more robust with popular offerings such as Django and Ruby on Rails, written in languages that empowered even faster web-development, the amount of data being transferred to users continued to increase. Many pages included rich media, advertisements, tracking & analytics, etc. Moving complexity in an application to the front-end via SPAs, typically built-in popular frameworks such as React, Vue.js, and Angular, allowed for the creation of pages with all the bells and whistles, but without the slow loading time from the server. Websites such as Netflix quickly elevated SPAs to a level that enabled users to never leave their web browser.

Advantages & Disadvantages

As web browsing has expanded to users wanting to connect from a variety of devices and still experience enjoyable browsing experiences, SPAs have greatly enabled dynamic sites to offer engaging content in ways that usurp the former superiority of traditional desktop software. SPAs can provide the same level of experience as software that needs to be installed on a user’s machine, offering you a faster path to providing the experience you want. The rapid growth of browser standards such as service workers and empower developers to bridge the offline and online experience, allowing you to keep users engaged even when a stable Internet connection is not available.

When developed correctly, SPAs do not have any inherent deficiencies in comparison to MPAs. The main challenge of proper SPA development is developer experience and consideration of some of the potential pitfalls, such as URL navigation. Browsers expect to interact with websites by following navigation in URLs, so while a SPA can do anything it wants in a particular session without altering the URL (since “true” navigation has not occurred), extensions and proper planning of application state allow you to update the URL while not actually making a new page request to the server, keeping typical browser navigation intact. SPAs move complexity off the server and into the browser, so the front-end engineers will have more to consider when it comes to state management and UX.

When to use a SPA?

SPAs should be considered when you want to provide a dynamic application-like experience to your users. They are best in situations where you know you will transmit a significant amount of data and have many interactions with that data on the page, or when the app you want your users to experience has many elements that depend on others. SPAs also make sense when you know multiple interfaces or services will be consuming the data from a particular server. Detaching front-end concerns by exposing back-end data only via application programming interfaces, or APIs, that are utilized by front-ends such as SPAs, reduces dependencies from a single point of failure and allows you to better scale front-end and back-end separately.

MPAs are still well-suited for more traditional browsing experiences where having a user navigate from page-to-page does not distract from the appearance. Modern websites typically offer SPAs and MPAs when appropriate, one choice is not the end-all of UX. For example, it may make sense to write a SPA for a complicated long-lived dashboard that offers data analytic modules, but the configuration pages may be better suited as simple form pages that don’t necessitate the additional complexity of a SPA.

Architecting for SPAs

SPAs allow for detaching the front-end from your back-end processing. They are isolated from the server and responsible for loading all data as well as handling states after the initial code is downloaded. This allows for better separation of back-end systems into services, providing application programming interfaces, or APIs, that can then be used for multiple front-ends.

Since front-end and back-end concerns are untangled, teams can make faster progress on improving each part of the stack in parallel. Server concerns do not need to have an impact on introducing techniques such as A-B testing, which guides your UX/UI and keep customers engaged.

Fortunately, incorporating SPAs into an existing tech stack does not have to be wholesale, as SPAs are still standalone pages that can exist in any infrastructure that serves Javascript to users. Existing back-ends can expose the data a particular application needs while still serving existing MPAs allowing incremental migration to incorporate SPAs and allow your engineering team to get up-to-speed.