Progressive Web Apps

A comprehensive guide for technical teams and project managers

Last Updated: February 16, 2020

Table of Contents

Introduction to Progressive Web Apps

Progressive Web Apps (PWA) are essentially web apps or websites utilizing service workers and other HTML5 APIs to provide native-like application features like push notifications, background refresh, cache. Google provides a comprehensive Checklist that covers most PWA features pretty well. PWAs have become increasingly popular. Early adopter innovative businesses as well as established brands are setting up PWAs or converting their websites to PWAs. Even businesses which prefer to have native applications are building hybrid applications using React PWA, Angular PWA, Ionic PWA with cordova bo build and generate native applications from the hybrid code.

Businesses and websites owners have been optimizing and making their websites responsive for mobile audiences as underlying technologies like browsers, devices and internet connection speeds have gone through changes and as usage patterns change . In the year 2018, the mobile audience grew to more than 50% of the total traffic across the web. Libraries and CSS frameworks such as Bootstrap (Twitter Bootstrap), Materialize, UI Kit have been enabling developers for setting up responsive sites to target a variety of resolutions and devices. WAP (Wireless Access Protocol) allowed businesses or website owners to setup separate mobile sites which were highly limited in features for the limited resolutions and screen real estates for the devices of the time. With modern mobile browsers integrating more and more of desktop features and modern HTML APIs, responsive websites have enabled the coding of one website – available to all devices, independent of device size and/or device type.

Latest mobile browsers support latest APIs like push notifications, local storage, cache, GPS, camera, service workers etc. thus allowing the browsers to leverage features like offline mode, background refresh, instant access to content via cache and IndexedDB and much much more. Compared to native applications, these web-browser based sites have limited scope and access to mobile hardware but their ability to provide an application like experience allows businesses to have lighter, browser based, lite applications instead of downloadable native applications from the platform stores.

Apple for their iPhone brought forward an idea of Web Apps, allowing websites to be treated as apps. iPhone and iOS users could create a shortcut to their favorite sites and the shortcut would appear as an icon amongst other applications. This was similar to bookmarks, but bookmark in your apps screen, limited to the technology and browsers of that time, push notifications and other HTML APIs were not available in the mobile browsers at that time. The term Progressive Web Apps (PWA) came from Google, allowing browser based sites to have more features and access to APIs like local storage, cache, push notifications, etc. Since then, chrome and other browsers have implemented support for these APIs and services.

Progressive Web Apps (PWAs) are hosted like any other website or web application, using a service worker to register its functions and features and allowing caching, background refresh, push notifications, etc. When added to home-screen, these Progressive Web Apps work like a normal native application. On clicking the icon, a splash screen opens up and the site or application is revealed in a virtual browser window without it’s address bar and other UI elements.

The Business Case for a Progressive Web App

Whether you a startup or a large established business, engaged in a B2C business or in B2B business segment, whether you have an e-Commerce web store or a static website with a service catalog a Progressive Web App can help increase your conversions and engagement level of target audience.

Business-to-consumers (B2C) businesses have already been using web apps and native apps to allow end-users shop from the comforts of their thumbs. Login, place an order, make the payment and you are done. Businesses in-turn use push notifications to alert their customers with order updates from “order in processing” to “order shipped” and finally – “order delivered”. Amazon, Flipkart, BangGood and many other e-Commerce platforms with B2C focus have slowly converted from highly optimized web apps to PWAs in addition to having independent native apps available across the native stores. The PWA application sizes are smaller compared to Native applications and any and all updates are automatically available to everyone without the need to download an update from the store.

Business-to-business (B2B) businesses have also started converting to PWAs and have noticed increased conversions and sign-ups. The one click “Add to homescreen” option allows quickly adding the PWA to their applications and access their dashboards. With increased number of millennial users, B2B PWAs (Progressive Wev Apps) are gaining more and more popularity and for good business reasons.

Whether you are a B2C oriented business or a B2B oriented business, PWA can help with your online presence and offer increased conversions using the simplicity of the web based application.

Even if you have a basic but an mobile optimized website, it can be converted to a PWA simlply by ensuring HTTPS (SSL) and by adding a manifest + service worker to your website.

Businesses have found that PWAs have less tech burden and are more reliable, engaging and easier to maintain and enhance. By using PWAs, businesses and website owners observed increase conversions compared to standard web sites because their offer offline support, caching and ability to subscribe to notifications from the browser based application itself.

Here is some data that is available on Google’s case studies into PWA about adoption and improvements helping businesses and website owners increase conversions and engagement.

  • AliExpress experienced 104% increase in conversion rates for new users, 82% increase in iOS conversion rate, 2X more pages visited per session per user across all browsers and 74% increase in time spent per session across all browsers

  •, a B2B company, experienced 76% higher conversions across browsers, 14% more monthly active users on iOS; 30% on Android and 4X higher interaction rate from Add to Homescreen

  • The Weather Channel PWA achieved 80% faster performance and it serves weather forecast to millions of users.

  • Twitter experienced 65% increase in pages per session, 75% increase in Tweets sent, 20% decrease in bounce rate

  • BookMyShow’s PWA drove an 80%+ increase in their conversion rates, the size of the PWA is 54x smaller than the Android app and 180x smaller than the iOS app, the PWA takes less than 2.94 seconds to load and enables checkout within 30 seconds.

Progressive Web App (PWA) Breakdown

The simplest form of a PWA is a website with HTTPS (SSL), manifest json file and a service worker. The manifest file contains the values for the UI colors, icons, splash screen and display mode for the PWA. The service worker in turn enables the background and native like features to the PWA. The service worker contains javascript that enables your PWA to offer ‘Add to Homescreen’ and be added as an application to the mobile. Since this PWA runs in a pseudo webbrowser mode, any and all updates to your website automatically reflect in the PWA without the need of downloading an update via the platform’s store.

Frameworks like React, Angular and Ionic generate PWAs that can either be hosted as Web Hosted PWAs or can be used to generate native applications by adding Cordova (Apache Cordova formerly PhoneGap). React PWA, Angular PWA or Ionic PWA generate HTML files that can be uploaded to any host. These frameworks add manifest and required service workers for notifications and other features.

Applications wrapped by Cordova wrapper can be uploaded to platform stores like Apple’s App Store and Android’s Play Store. These applications can be downloaded from the stores after approval.

The MVP of having an web based PWA is that updates do not require submissions to the native platform stores. Updated code can be uploaded to the webhost and same would reflect across browsers and platforms.

The PWA experience

Before discussing steps and features of PWA in detail, lets experience a PWA in action. What is the “Add to homescreen” option, what is the native like UI experience, what is the offline capability and how it all varies across devices.

Service Worker

Service worker is the building block of a PWA. This code registers the website as an PWA and tells the browser about the features that the PWA supports and is configured to use. The service worker is responsible for background refreshes, offline caching, support for push notifications and so on.

Let’s look at the compatibility of Service Worker with different browsers before moving forward. As you can see from the compatibility chart below, all major current browsers support service workers. However, service worker compatibility does not mean automatic support to any and all PWA features.

Add to Homescreen

The “Add to Home Screen” web app install prompt allows users to add your Progressive Web App to your applications list. After accepting the prompt, the mobile browser creates a WebAPK and installs the PWA. On desktop, the app is installed as an Chrome application and opens up in an independent browser mode.

Push Notification

Push notifications in Progressive Web Apps are powered by the service worker. Push notifications have a two part procedure, the web push which is handled by the browser. The service worker on receiving a message allows the web app to display the notification using the Notifications API.

Native like UI

After adding to your homescreen or your applications list, the PWA can be opened like any other application. This application, if configured to display as “standalone” appears like any other application, that is without the browser address bar or the browser interface and buttons.

These features can be leveraged using the service worker. The web application will seek user’s permission before enrolling the user’s device before adding to homescreen or allowing notifications to be enabled on the device.

Offline support & caching

Progressive Web Apps (PWA) allow both caching and offline support. In addition to specifying what pages and content (css & js) are to be made available offline – when both the WiFi & Data are not working; PWA can use various storage APIs for accessing content locally in addition to web based cloud storage.

Currently, a web app or PWA can access the following (online & offline) APIs for storage

  • File system

  • Local Storage

  • Session Storage

  • Cookies

  • WebSQL

  • Cache

  • IndexedDB

  • Cloud Storage

A PWA can identify when your phone or device does not have any working connection and then the offline mode kicks in.

Cache API allows storage of requests and responses from the web app. This API can also be used as a simpler storage mechanism as the API only allows data storage in key/value pairs. However, data stored in cache can not be searched.

IndexedDB is like a local database that is available to the application where the application state or application data can be stored and accessed locally to the application. IndexedDB allows instant access to the data and allows the application to update the app state or any other data without internet access.

Converting your website to a PWA

The simplest form of an PWA is any web hosted site or page with HTTPS enabled, a manifest file with the theme colors, etc and a service worker.

Google lighthouse testing evaluates a lot of factors which include speed and other indexes. However, any site to qualify as a basic PWA needs to follow the above three conditions. Having a mobile optimized website or an AMP website can definitely help improve the lighthouse or benchmarking results and that definitely is another topic to discuss.

Here is the code snippet of our (eSided) own manifest (json file) and service worker files. Please note that the service worker needs to be linked to the website, in our case we prefer the homepage footer. This is done by inserting a few lines of code to register the service worker if the browser supports it.


{"name" : "eSided Business Solutions", "short_name" : "eSided", "description" : "eSided is focused at optimizing B2B Manufacturing & Wholesale Companies via eCommerce, Digital Strategy, Lean IT & Transformative Leadership.", "start_url": "", "display" : "standalone", "orientation" : "portrait", "lang" : "English", "background_color" : "#029cfc", "theme_color": "#029cfc", "icons": [ { "src": "/pwa/1feb96098abb.png", "sizes": "44x44", "type": "image/png" }, { "src": "/pwa/efcfba2d20dc.png", "sizes": "48x48", "type": "image/png" }, { "src": "/pwa/9988a4fcaf6f.png", "sizes": "1240x600", "type": "image/png" }, { "src": "/pwa/9ce5f2a48592.png", "sizes": "300x300", "type": "image/png" }, { "src": "/pwa/5ceb7e9cc828.png", "sizes": "150x150", "type": "image/png" }, { "src": "/pwa/70891d6e512c.png", "sizes": "88x88", "type": "image/png" }, { "src": "/pwa/eb135eaedc09.png", "sizes": "24x24", "type": "image/png" }, { "src": "/pwa/902e8c316a99.png", "sizes": "50x50", "type": "image/png" }, { "src": "/pwa/70f6aa17e976.png", "sizes": "620x300", "type": "image/png" }, { "src": "/pwa/d2ad38bd9c18.png", "sizes": "192x192", "type": "image/png" }, { "src": "/pwa/489a894a121f.png", "sizes": "144x144", "type": "image/png" }, { "src": "/pwa/58264ccdd554.png", "sizes": "96x96", "type": "image/png" }, { "src": "/pwa/1bc93803bef1.png", "sizes": "72x72", "type": "image/png" }, { "src": "/pwa/514d1d4ee0bf.png", "sizes": "36x36", "type": "image/png" }, { "src": "/pwa/2d25b110479a.png", "sizes": "1024x1024", "type": "image/png" }, { "src": "/pwa/923cc1cd1c10.png", "sizes": "180x180", "type": "image/png" }, { "src": "/pwa/ad8efab45582.png", "sizes": "152x152", "type": "image/png" }, { "src": "/pwa/4078b937ad31.png", "sizes": "120x120", "type": "image/png" }, { "src": "/pwa/c802e50cee6d.png", "sizes": "76x76", "type": "image/png" } ]}


self.addEventListener('fetch', function(event) {});

Script for the webpage/homepage/website (ideally in the footer)

<script type="text/javascript">

if ("serviceWorker" in navigator) {

window.addEventListener("load", function () {





Auditing and benchmarking the PWA

Let’s look at what factors and tests the Google Lighthouse tool evaluates for when auditing a web-app / website as a PWA

  • Fast & Reliable

    • Page load is fast enough on mobile networks

    • Current page responds with a HTTP 200 when offline (offline page specified)

    • start_url (via manifest.json) responds with a 200 (HTTP code) when offline (offline page specified

  • Installable

    • Uses HTTPS

    • Registers a service worker that controls page & start_url

    • Web app manifest meets the installability requirements

  • PWA Optimized

    • Redirects HTTP to HTTPS

    • Configured for a custom splash screen

    • Address bar (browser UI) “theme-color” has been set using the meta “theme-color”

    • Content is sized correctly for the viewport

    • Has a meta name=”viewport” with width and intial-scale

    • Contains some content when JS is not available

    • Has an apple-touch-icon

The following manual tests, which are not done by the tool but are essential when you are testing your PWA

  • Site works cross-browser

  • Page transitions don’t feel like they block on the network

  • Each page has a URL

Let’s take a look at how to audit a website or webapp using the Lighthouse tool. We are going to use the Lighthouse audit from chrome devtools. It is advised to disable the chrome plugins or use the incognito mode before testing your website or webapp.


As and when you started implementing PWA or converting your existing site/application to PWA, you will realise that there are some security challenges that are mandatory to not overlook.

Your hosting or existing site might not give you the access you need to start converting your site or application to PWA. In this article, I will be sharing the challenges faced by our team while converting sites to PWA and how we overcome those.

Pre-requisite — SSL

SSL ( Secure Socket Layer ) is responsible for encrypting the transport link between the client’s browser and the server. Every time a link is established, the browser checks the certificate of the site and makes sure it’s valid and has not expired. In case of an invalid certificate, a warning or error is shown alerting the user of possible SSL error.

SSL is a pre-requisite for PWA and if SSL is not enabled then you might not be able to setup PWA. If you have no idea about whether your site is secure and SSL enabled, you can check if your site answers at https:// or ask your webmaster or web host.

Challenge #1 — Scope of service worker

The scope of service worker can prove to be a challenge based on your existing setup or the stack being used by you for your website. The service worker JS has two components. A set of code that goes into your website’s template or HTML code which points the browser to the service worker’s location.

Ideally the service worker js file should be located at the same directory level as the root of the site. Basically, if your website is, then the service worker should be accessible and available at

The JS file name is not significant and can be anything you like or want however it’s location is very significant. The service worker will only work in the directory and the children of the directory in which the service worker is located.

Ideally with development environments which allow access to the site or domain root, placing a service worker js file in the root is easy and proves not to be a challenge allowing successful registration of the service worker and it’s scope to include the site and it’s children pages and sub-folders.

While registering your service worker, you can check and view it’s scope using the code below especially line #8 & line #9 where the registration scope is being logged to the console.

<script type=”text/javascript”>

if (“serviceWorker” in navigator) {

if (navigator.serviceWorker.controller) {

console.log(“eSided service active worker found, no need to register”);

} else {



.then(function (reg) {

console.log(“eSided worker has been registered for scope: ” + reg.scope);





When the development environment does not allow you to access the domain root directly like is the case of Big Commerce, NetSuite, and similar platforms, the scope proves to be a challenge that needs to be solved in order for proper service worker registration and installation.

A point to be noted here is that you also have the option to specify the scope of the service worker, but you can not specify path outside or above the location of your service worker.

Challenge #2 — Cache

Amongst other features, service worker allows you to cache your site and make it available from the browser cache in case your device loses connectivity or in case you want to make the files stored and refreshed in the background.

While optimising and implementing a cache, a common challenge is specifying what is needed to be cached. It is easier to implement a no-restriction caching for your site, but this can lead to an infinitely increasing foot print (cache size) of your site. The service worker might end up caching any and all requests not just the static assets of your site. Even if you specify to cache only static assets which might also include images, the service worker might end up caching the full size images.

Our site has only a few posts as of now, and yet we reached close to 980Mb of cache storage in under an hour of browsing of the site pages and posts. Here is a quick screenshot to give you an idea of what poor coding can end up doing.

Ideally, I would suggest combing through your JS & CSS files and optimising your service worker to cache the theme and mandatory JS & CSS files. A good resource to read more about this would be Jake Archibald’s Offline Cookbook which is located at

Challenge #3 — Choosing the correct content serving mode

There are multiple approaches to serving content. All of these approaches allow you to intercept network requests and respond with files or content based on your preference from the below (not limited to these, other options also available):

(1) Cache only

(2) Network only

(3) Cache failing back to network

(4) Network failing back to cache

(5) cache then network

Using the correct mode to serve your content, can make quite the difference and can help with speed & performance boost leading to better conversions and user retention on the PWA.

A site with offline page and no-cache can qualify as a PWA, however, caching content not limited to static resources can make more of the site or PWA available to users with unstable connections and in offline mode.

A B2B site might chose to make their contact pages, policy pages, offers available offline and cached while a simple website might chose to make all essential JS, CSS and content available offline and cached. The correct content serving mode will vary based on your site and intended setup.

Tools & Resources