Progressive Web Apps: The Non-Technical Guide
This is part 1 of a multi-part guide to progressive web apps for those who do not have advanced knowledge of web technologies. This part of the guide will answer the question “what is a progressive web app and how does it differ from a native app?”. The future posts will compare the two technologies in more depth and explain the reasons you might choose one over the other.
Progressive Web Apps (or PWAs for short) are a trending buzzword in the technical web development community (Google even held a summit in 2016). While the focus of a lot of this buzz is within the tech community itself, it will (for the most part) be people outside the tech community who will have to decide whether their next smartphone app should be a progressive web app. Unfortunately, there aren’t many guides to progressive web apps for people who aren’t actively involved in app development. Part of the service PastPortal offers its clients is help in choosing whether to publish a progressive web app or native app from our platform, so we thought we would write this series of non-technical guides with the basics. These guides will explore the “what” and “why” of progressive web apps, rather than the “how”.
What is a native app?
Before we explore progressive web apps it is worth quickly considering what they are an alternative to: native apps.
Simply put, native apps are traditional smartphone apps. They are made available to users through the store provided with the operating system (i.e. PlayStore on Android and App Store on iOS). They have access to almost all of the sensors on your phone, although some of these sensors require express permission given by the user (such as when iOS asks whether you should give an app access to your camera). Many of the more popular apps on your smartphone will be native apps.
What is a progressive web app?
In contrast to native apps, progressive web apps are essentially websites optimised for mobile that users can add to their home screen and have the appearance and usability of native apps. They are not available on PlayStore or the App Store, instead users are invited to add the app to their home screen while visiting a web site owned by the app creator.
What often makes the discussion of progressive web apps very technical is defining what is meant by having the appearance and usability of a native app. These discussions inevitably refer to the tests specified in a tool made available by Google called lighthouse. The top level tests are:
- the app can load on offline/flaky connections;
- the page load performance is fast;
- the site is progressively enhanced;
- the network connection is secure;
- users can be prompted to Add to Homescreen;
- the installed web app will launch with a custom splash screen;
- the address bar matches brand colours; and
- the design is mobile friendly.
Some of these tests tell the whole story (e.g. that users can be prompted to Add to Homescreen), others are a bit more nuanced. Let’s look at some of the nuanced tests in more detail to better understand what a progressive web app is.
The page load performance is fast
The main thing worth discussing here is what speed is being measured (hint: it isn’t just page load time).
One of the more important measurements reflects a performance disadvantage that progressive web apps can face if poorly coded, the time for the screen to update in response to a user input (known as input latency). If this delay goes above 100ms it is likely that it will be perceived by the user (the impression that the change on the screen is an immediate response to the user’s input will be lost). Accordingly, this is measured in the tests (and the limit is set lower, at 50ms).
The other measurements all relate to different aspects of page load speeds. There are three aspects of this performance that are measured: (i) the time it takes for the user to first see anything (even if it is just a loading spinner and the branded toolbar, more on that below), (ii) the time it takes for the first page of visible content to load and (iii) the time it takes for the user to be able to start interacting with the content (i.e. a tap or swipe on the screen will result in the desired action). The aim is for all of these to be as quick as possible to enhance the user experience.
The site is progressively enhanced
According to Google: “progressive enhancement means that everyone can access the basic content and functionality of a page in any browser, and those without certain browser features may receive a reduced but still functional experience.” However, many of the discussions around this requirement have concluded that it is more focussed on the experience of users with slow connections, rather than the experience of users that don’t accept JavaScript functionality.
So in practice this test means that your page shows something before the main business logic of your app (in the case of a progressive web app, the JavaScript) has been fully downloaded. In most cases, this means that the first paint (the first thing the user sees) includes a template for what the content will look like and a complete visualisation of the toolbar (even if it lacks interactivity at that point). A good example of this that you may have seen very recently if you are reading this article on Medium is the loading screen for the Medium app, pictured below:
We hope that you now have the first piece of the puzzle in understanding the choice between progressive web apps and native apps — the answer to what a progressive web app is. In the next part of this guide we will explore the differences between the technologies in more depth and explain the reasons you might choose one over the other. Make sure you don’t miss out on the next part of this guide by following the PastPortal publication on Medium. Alternatively, head here to sign up for our email list.
