How to build a Progressive Web App

Progressive Web Apps (PWAs) are web applications that load like regular web pages or websites but can offer the user functionality such as working offline, push notifications, and device hardware access traditionally available only to native mobile applications. PWAs are an emerging technology that combine the open standards of the web offered by modern browsers to provide benefits of a rich mobile experience.

A Progressive Web App is:

Progressive – Works for every user, regardless of browser choice because it’s built with progressive enhancement as a core tenet.
Responsive – Fits any form factor: desktop, mobile, tablet, or whatever is next.
Connectivity independent – Enhanced with service workers to work offline or on low-quality networks.
App-like – Feels like an app, because the app shell model separates the application functionality from application content .
Fresh – Always up-to-date thanks to the service worker update process.
Safe – Served via HTTPS to prevent snooping and to ensure content hasn’t been tampered with.
Discoverable – Is identifiable as an “application” thanks to W3C manifest and service worker registration scope, allowing search engines to find it.
Re-engageable – Makes re-engagement easy through features like push notifications.
Installable – Allows users to add apps they find most useful to their home screen without the hassle of an app store.
Linkable – Easily share the application via URL, does not require complex installation.

1. Serve over HTTPS

Let’s be honest: you should be doing this anyway. SSL adds an extra layer of security to the web, helping your users feel secure in using your site. With PWAs, HTTPS is essential for using service workers and allowing home screen installation. You can purchase an SSL certificate from your domain registrar at little expense and then configure it through your hosting service.

2. Create an application shell

Your app shell is the first thing that loads – the first thing the user sees. It should be exist entirely in your index HTML document, with inline CSS, to ensure it appears as fast as possible and your user isn’t staring at a white screen for longer than necessary. The application shell forms part of the pattern of progressive enhancement. Your app should give the user content as soon as possible, and then progressively enhance it as more data (likely JavaScript) loads.

The example below is taken from a React.js application. The user is presented with an outline of the app and a loading indicator in the index.html. Then, once the JavaScript loads and React boots up, the full application is rendered within the shell.

3. Register a service worker

To tap into the full spectrum of PWA goodies (push notifications, caching, install prompts) you will need a service worker.

Luckily, they’re pretty easy to set up. Below, we first check if the user’s browser supports service workers. Then, if so, we can move ahead with registering the service worker file, here called service‑worker.js. Note that you don’t need anything special inside that file at this point – it can be blank.

In the example below, however, we show how to tap into the three key service worker lifecycle events. These are ‘install’, when the user first visits your page; ‘activate’, right before registration completes; and ‘fetch’, when the application makes a network request. The last one is relevant for caching and offline capability.

4. Add push notifications

Service workers allow your users to receive push notifications via the web Push API. To access it, you can tap into self.registration.pushManager from within your service worker file. Since the sending of push notifications relies heavily on your backend setup, we won’t dive into it here.

If you’re starting an app from scratch, Google’s Firebase service comes with Firebase Cloud Messaging for relatively painless push notifications. The code below shows how to register for push notifications via the Push API.

5. Add a web app manifest

In order to make your application installable, you need to include a manifest.json in the application’s root directory. You can think of this as a description of your application, similar to what you might submit to the App Store. It includes icons, a splash screen, a name and a description.

There’s also some configuration for how your application appears when it is launched from the user’s home screen: Do you want to show the address bar in the browser or not? What colour do you want the status bar to be? And so on. Note that a proper manifest.json should include a full spectrum of icon sizes for various devices. The code below is a preview of some of the properties your manifest can include.

6. Configure the install prompt

When a user visits a PWA with a service worker and manifest, Chrome will automatically prompt them to install it to their homescreen, given the following: the user must visit the site twice, with five minutes between visits.

The idea here is to wait until the user demonstrates interest in your application, and then ask them to make it a fixture of their device (this is in sharp contrast to the native app approach, which asks for that investment up-front).

But there may be cases where you want to show the install prompt in different situations, such as after the user takes a particular useful action. To do so, we intercept the beforeinstallprompt event and save it for later, then deploy the prompt when we see fit.

7. Audit your app with Lighthouse

Google is the biggest champion pushing Progressive Web Apps as the future of the web. As such, it has supplied a useful tool for guiding your PWA development.

Formerly called Lighthouse and supplied as a Chrome Extension, as of Chrome 60 it’s a part of the Chrome DevTools, under the ‘Audits’ tab. What Lighthouse does is run your application under different conditions and measure its response and success according to PWA guidelines. It then gives you a score out of 100. It can also score your app on web best practices at the same time.

The following text is a list of the values Lighthouse measured. In use also shows descriptions.

  • Registers a Service Worker
  • Responds with a 200 when offline
  • Contains some content when JavaScript is not available
  • Uses HTTPS
  • Redirects HTTP traffic to HTTPS
  • Page load is fast enough on 3G
  • User can be prompted to install the Web App
  • Configured for a custom splash screen
  • Address bar matches brand colours
  • Has a tag with width or initial-scale
  • Content is sized correctly for the viewport

Do you have any business ideas to built? We are ready to help! 41studio is Agile Ruby On Rails Development Company & Consultancy that leverages the cutting edge technology to rapidly build web, mobile and desktop applications. Tell your idea to us and we will gladly help.