The benefits of single page applications and progressive web apps: Improving CX

by Branwell Moffat, e-Commerce Director of Envoy KPS

The benefits of single page applications have become more and more clear as the customer experience requires e-commerce providers to deliver quick, reliable interactions with them.

Over the last 20 years, most websites have been built in the same way – with the use of HTML, CSS, and JavaScript. These technologies have become more advanced over time, but the principle has largely remained the same: A user interacts with a webpage and the user’s browser makes a call to a web server which, in turn, responds with another batch of HTML, CSS, and JavaScript, which is then loaded and displayed in the browser. (Whew. That’s a lot.)

This process most commonly involves the page being refreshed, although some technologies, such as AJAX, do enable developers to alter some content without refreshing the entire page. Because of this, most websites act and behave distinctly like a website, rather than an application.

Most websites also have a tightly coupled back-end and presentation layer, meaning there is no real separation between the front and back end of a website, as both are part of a single monolithic application.

How single page applications and progressive web apps can improve customer experience

Over the last decade, native iOS and Android apps have become common place for almost all of us. These applications behave differently than actual websites, providing users with a very different, and often more satisfying, experience.

Pages don’t refresh when a link or button is pressed, changes load much faster, and the experience is often a lot better than the equivalent mobile website. In the case of a native e-commerce app, when a user clicks on a link, the application will make a call to a back end server, but rather than that server returning the HTML, CSS, and JavaScript presentation layer, it is simply sending the required raw data, and the application manages how that is displayed to the user.

For example, if a user clicks on a product to view its details, the application will call the back end server asking for the details of that product and the server will respond with a string of data that contains items such as the product name, its price, and a link to an image, but doesn’t need to also send any HTML, CSS, or JavaScript to define how it will be displayed.

The application itself is the presentation layer, so it doesn’t need any of that from the back end server. This is much faster and allows the application to display the product details to the customer without refreshing a page. The technology gives developers freedom to build a seamless and fluid customer experience without the constraints of the traditional model.

Wouldn’t it be great if an app-like experience could be provided through a web browser so that the distinction between a native app and a website becomes blurred?

This is where Single Page Applications (SPAs) and Progressive Web Apps (PWAs) come in.

What is a Single Page Application?

An SPA is an application written in JavaScript that runs in a web browser, and generally doesn’t require a page refresh to show new information.

When a user first visits the website, the application, along with presentation resources (HTML, CSS, and some scripts) are loaded into the browser. From this point onwards, the user is on a single web page, and the application is loading the relevant content and altering the display as and when required.

Just like a native app, when a user clicks on a link, the application calls the back end server, which in turn sends the required data in a string, which does not generally include any of the presentation resources, as they’ve already been loaded when the user first visited the website.

Because the user is essentially only on a single web page, there isn’t really a concept of refreshing a page. Instead, the application alters the page to show different information when required.

SPAs are generally entirely de-coupled from the back end application and interfaces to the back end through a set of APIs.  It will often sit on its own server and can deployed separately. In a way, it’s quite agnostic towards the back end application, as it’s simply sending and receiving data to and from it – treating it like a 3rd party system.

We’ve all been using SPAs for a while now, probably without even realizing it. Facebook, Gmail, Twitter, LinkedIn, and Instagram (among many others) all use SPAs in place of their websites.

If you visit any of those websites now, you’ll notice that they behave much more like a native app than a traditional website.  Pages rarely, if ever, refresh when you interact with them, and are very fast. Clicking on links and buttons changes the content you’re looking at, but items like the header and footer almost never refresh once they’ve  initially loaded.

Benefits of Single Page Applications

The biggest and most obvious advantage of an SPA is how they can be used to improve customer experience by allowing designers and developers to provide an app-like experience and not be constrained by the traditional approach of reloading pages.

This does require a new way of designing and thinking, as the normal rules no longer apply, but the benefits to the user experience can be massive.

SPAs generally load content much faster than standard websites, as much of the presentation resources (HTML,CSS) are loaded only once. Interactions with the application only require a call to the back end server to retrieve small amounts of data, rather than fully formed HTML/CSS pages. The application can then rapidly display the changed data without having to reload the page.

Because an SPA is entirely de-coupled from the back end application, it can deployed separately, which can have a very big advantage. A small front-end change will not require the entire application to be deployed which can be quite a big task and sometimes requires downtime.

Disadvantages of an SPA

One of the biggest challenges of using SPAs is the impact it has on SEO. As they don’t always have the traditional structure of distinct pages, each with a distinct url, this can cause issues with search engines indexing the content. However, this can be countered with the use of techniques such as server-side rendering and ensuring that clicks do generate unique urls.

It’s also becoming less of an issue over time, as search engine bots are being changed to cope with SPAs. Google is one of the companies championing them, after all.

Some SPAs take a little time to load on the first visit because the application and presentation resources are loading on the first page view.

This is very noticeable with SPAs such as Gmail, where they have a big loading image when you first visit the website. This issue can be countered with the use of server-side rendering and efficient programming to ensure that the initial load of the application and resources is not too big.

What is a Progressive Web App?

A PWA is a little hard to define, as it’s not any specific technology, but more of a development methodology or set of principles that together make a website or application more or less PWA.

The term PWA was originally coined by Google, who created a checklist to define what makes a PWA. Among other things Google have defined that a PWA must be:

  • Safe – served under https
  • Responsive – fit any form factor
  • Able to work offline – using service workers to cache pages
  • Fast – able to load fast on a 3G connections
  • App-like – using app-shell mode and design to feel like an app
  • Installable – use a manifest file to allow app to be added to home screen
  • Engaging – using tools such as push notifications
  • Progressive – works on all browsers but is progressively better on modern browsers

As you can see, some of the checklist items are a little vague or subjective. You can also see that some of them sound similar to an SPA. A traditional HTML/CSS website can be made into a PWA as can an SPA. An SPA isn’t automatically a PWA, but has some features that push it in that direction.

Confused yet?

Advantages of PWAs

As with an SPA, one of the biggest advantages of a PWA is the improvement in the customer experience, giving it an app-like feel and bridging the gap between a traditional mobile website and a native iOS or Android app.

Features like the ability to save to your home screen or being able to cache pages through service workers can make the website look and feel a bit like a native app.

PWAs also tend to be very fast, as that’s one of the key principles in the checklist.

The Android operating system gives browsers access to the hardware of the mobile device. which allows things like push notifications and use of NFC scanning, which can really improve the CX.

Disadvantages of PWAs

The biggest disadvantage of PWAs is the lack of support from Apple. To get the best out of a PWA, it really needs to run on an Android device, as the Android operating system gives browsers access to a significant amount of features on the device, whereas Apple severely restricts this. This is slowly improving, but there’s still a long way to go.

Another disadvantage is the lack of a clear definition, which can be open to interpretation.

SPAs and PWAs are the future of website development

Although this technology is still not entirely mainstream for most e-commerce websites, it’s undoubtedly the future of website development.

While SPAs are a specific technology that can be used to build an e-commerce application, PWAs are generally websites that’ve been built following a methodology laid out by Google, which they feel provides the best customer experience.

Anyone developing an SPA should aim to meet the PWA checklist as much as possible in order to provide the best possible CX. These technologies give designers and developers more freedom in the user experience and journeys, allowing them to move away from the traditional page by page model.

Many software providers like SAP and IBM are heavily investing in creating SPA front ends for their e-commerce platforms, and I suspect that within a few years, most e-commerce websites will be built in this way, using JavaScript frameworks such as Angular, Vue, or React.

Fewer and fewer e-commerce sites will be built using the traditional HTML/CSS model, and the gap between websites and native apps will get smaller and smaller, to a point where it’ll be hard to distinguish between them.

For more articles by Branwell Moffat also see https://www.the-future-of-commerce.com/contributor/branwell-moffat.