Progressive Web Apps: The Offline-First Approach

We have a good amount of Web Apps which are using the Progressive Web App format and are doing great. Some of the examples can be found here Recently Google had a dedicated summit for Progressive Web Apps and we had a great number of developers talking about the experiences.

For making your web app into a progressive web app we need to have a serviceworker.js file, a manifest.json file to do the magic. The manifest file contains the details of the app, like: name, icons (for different devices), theme color, display orientation, a start url, splash screen and much more.

Once we have this manifest file working we can add our app to the home screen of our device and it will give us an app like user experience. However when you are offline and a user taps on the app icon on his home screen, the UX can be pretty bad as the browser will say that “you are offline” and this completely gives a web app experience and not an app like experience.

The Disappointment

Being offline is not the only case where your app looks bad but there is also one more case to consider “a conky network” i.e when you are connected to the internet but it isn’t working at all or it is very much slow, in this case what a user will see is our splash screen all the time till he gets the better connectivity or something from the server to show up and with this the UX is worsened more.

To overcome the states that we got into we can shot it by offline-first standard i.e we show the offline content that we have first and then when we get on to the network we show the new content (and this is what the real apps do). To begin with we need to register our service worker, we should have a minimum application shell that is required to make a good UX (it can be header, the footer, some main content if needed), and we need to cache the application shell and this can be done using the install event in our serviceworker.js file and we can cache files that are needed for our application shell to be visible to a user when he is offline or has a bad connectivity.

Once we have the install event complete we need to cache our shell and this can be done in the fetch event where we check if the URL is the home i.e “/“ we show a cached version first till we get the new content from the server. This way when the user page requests the Url it goes through service worker and the service worker gets the content from cache and takes it to the page and once the content is shown on the page from the cache the request goes to the server and if this server request fails we are still showing a cached version of the content to our users and they won’t be disappointed this time.

In the next series I will write a detailed post on how to integrate an offline first app and how to make our UX better.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.