Progressive Web Apps or PWAs are ruling the tech world. Since their arrival, almost every application is moving towards becoming a progressive web app or is planning to do so. In our previous post on progressive web apps, I explained what a progressive web app is and what goes into testing a progressive web app.

So, let’s move to the next level now.

In this blog, we will discuss the challenges that organizations face while moving their web application(s) to progressive web application format and how these challenges can be overcome.

Which Framework to Use While Building A Progressive Web App

When you plan to upgrade to a PWA or to build a PWA, the first question that makes you scratch your head is what framework should I use? Vue.js? React? Preact? Or something else?

Well, to figure this out, we did a bit of research on some companies that have upgraded to a PWA to find out what the most used framework is and why.

From our research, we figured out that many of the companies used React, so we decided to dig further into it. We analyzed case studies of products like Garbarino and Twitter Lite and found that the main reason for choosing the React framework is its usability, online support, and familiarity with legacy frameworks.

Moreover, React also provides you with the following advantages over the other frameworks:

Since Facebook manages and supports it, this framework is rigorously tested by 2.2 billion users daily. Being the foundation for React Native, React lets you port applications built with React to native apps easily.

Even though there are more big firms using React, in our view, all of the above-mentioned frameworks give React stiff competition. Ultimately, it’s up to your team. You can choose any of the frameworks which suit your requirements and that are handy to the people in your organization.

Single Page Application or Multi-Page Application?

Before you get started building a PWA, you need to build an application first. While doing so, there are two options for what your application can be. You can go with an SPA (Single page application) or you can develop an MPA (Multiple Page Application).

Yeah, I totally understand the face-palm moment here. There can be only these two type of apps.

So the main question here is, which is the best approach? Well, that depends on the objectives you are trying to achieve by building a PWA.

A single page application, or SPA, is an application that works as a single page and doesn’t need to reload or redirect to a new page when you send some request from it. It’s like a Gmail or Facebook app. So, if you’re migrating from your already built application to a PWA because you want to increase your page loading speed or other factor related to loading speed, then I would suggest you go for an SPA. Some PWAs that use an SPA model include Twitter Lite, Housing Go, Flipkart Lite, Polymer Shop, etc.

However, if you want advantages like isolation and decoupling between pages, you can go for an MPA. While building a mobile site, it allows you to build its different parts as ‘microservices’ which in turn allows you to iterate on these services independently, embed them into third-party apps if needed, and can even be maintained by different teams. One organization that used MPA model to build their PWA is Ele.me.

So, you can use the given information to go for SPA or MPA.

Having Problems While Caching the App Shell?

When building a PWA, you aim to deliver faster performance to your clients. Caching the app shell helps you reduce your page load time by caching the pages offline to ensure better performance to users on multiple visits.

You can use a static asset precaching tool like sw-precache or you can prompt the caching of pages using manually written service workers.

When caching manually, you can use the following code:

var cacheName = 'shell-content'; var filesToCache = ['/css/styles.css', '/js/scripts.js', '/images/logo.svg', '/offline.html’, ' / ’, ]; self.addEventListener('install', function(e) { console.log('[ServiceWorker] Install'); e.waitUntil( caches.open(cacheName).then(function(cache) { console.log('[ServiceWorker] Caching app shell'); return cache.addAll(filesToCache); })); });

As per Twitter Lite, after enabling the ServiceWorker pre-caching, they improved from 6 seconds load time to less than 1.5 seconds. That’s a flat 75% improvement!

Let’s AB Test!

AB testing comes as an aid in case you want to monitor some of the factors in your PWA, like conversion rate, bounce rate, time in app, etc.

So you need to do testing and it requires data.

Data, data, and lots of data. You heard me and collected an ample amount of data. But what do you need in order to monitor? How do you monitor? Do you find this question difficult to answer?

If no, great!

If yes, no worries! We have an answer for you.

Here are some of the difficulties that you might face while monitoring the various factors:

Separating google analytics.

Measure conversion rates in and out of PWAs, like cart and checkout, as in the case of e-commerce PWAs.

Having the same URLs on both sides of the experiment.

People who saw A should see A but those who saw B at first should see B.

For the first two use cases, you can configure a new view on the analytics based on some custom dimensions. The dimensions must be populated directly via the PWA's code and based on a cookie.

For the last two points, all you can do is to send all the traffic to the PWA. There, a random draw decides if you continue there or if you will be redirected to the mobile site. Once you are done with this, you can store this choice in a cookie ‘forever.’

Once you solve all the hurdles and buckle up to release a PWA version of your application. all you need to do is sit back and see the results while debugging.