Progressive Web Apps: Bridging the Gap Between Web and Mobile

In this article, we’ll go through the basics of what a progressive web app (PWA) is, study some real life cases, and explore other uses and situations in which a PWA can be used to great effect.

Nowadays, significant numbers of people are connected to the internet almost everywhere they go. There are, however, still an even larger number of users with intermittent access, such as users on mobile data plans, shared internet access and so on. Catering to these users requires changes to the information flow we’re used to.

By allowing users to keep browsing once they’re offline, serving the pages they’ve already visited, it’s possible to retain visitors and customers who would otherwise be in the dark once their internet is cut off.

It’s even possible to use the cached data and program functions for that, allowing for interactivity similar to mobile applications, but without the need for the user to download an app via the various app stores, and similarly, without the need for submitting to them as well.

What is a Progressive Web App?

When trying to understand what exactly a progressive web app is, it might be easiest to compare relative to both websites and mobile applications. In the table below, some, not all, of the more prominent features are sidelined with PWAs in the middle, symbolizing the gap-bridging functionality of the progressive web apps.

Features	Website	Progressive Web App	Mobile App
Offline	NO	YES	YES
App Stores	NO	NO	YES
Responsive	YES	YES	YES
Searchable	YES	YES	NO
Local notifications	NO	YES	YES
Push notifications	NO	YES	YES
Download to install	NO	NO	YES
Fast updates	YES	YES	NO

Keep in mind that the entire term “progressive web app” loosely contains a number of relevant and some irrelevant information and criteria. Technically, there are four requirements (see below) that define what a PWA is, currently supported by Google Chrome, Opera and Samsung Internet.

Once these four criteria are fulfilled, developers are free to customize the functionality according to their own wishes, so we can see both offline error pages, and full-on offline browsing depending on what project and site we’re visiting.

Becoming Progressive

In order for any online site to be recognized as having a progressive web app installed on the server — and thus include the prompt “Add To Home Screen” for users — there are four main requirements as set out by Google:

• a site must be visited twice with a 5-minute interval to qualify
• secure HTTPS connection Valid
• JSON Manifest installed Valid
• Service Worker installed.

Site must be visited twice with a 5-minute interval to qualify

In Google Chrome, it’s necessary for users to have visited the site hosting the PWA twice before the browser will show the prompt for installing the PWA.

It’s not the most reliable form of verification, but nonetheless, it seems to work fine, as first-time visitors won’t get bombarded with the prompt taking up 25% of a mobile screen, and furthermore, it ensures that users are somewhat interested in that particular site, seeing as how they’ve already visited it before.

However, this is a simple way of determining user relevance and interest, and one could guess that this qualification parameter will be changed to something more substantial in the future. But for now, it seems Google developers are content with this measurement.

Secure HTTPS connection

By having a secure connection to the progressive web app, users can feel relatively safe by allowing permissions to the PWA.

Since the network requests are routed through the service worker script, adding https to the server helps to mitigate certain vulnerabilities such as snooping.

While this requirement might be focused mainly on adding safety from hijackers, having a secure connection also helps build trust with users. And since PWAs are indexable by search engines, it also makes sense to serve over TLS, since it adds a small amount of benefit SEO-wise.

Valid JSON Manifest installed

By providing a data extract in the format of JSON, it’s then possible to cache this information with the help of the service worker, and then use the app shell to load CSS rules to deliver an offline version with full UI capabilities.

Any time a visitor loads a new page, the service worker will cache the JSON extract, and store it physically in the app shell. This app shell is a self-contained wrapper that has all necessary style sheets, scripts, images, fonts and HTML outputs required for a user to render a complete page without loading anything else.

Compared to a website, a PWA has the capability of still showing data when the users are no longer connected to the internet.

Valid Service Worker installed

This can be classified as the bread and butter of any modern progressive web app. The service worker is responsible for caching all files, serving push notifications, content updating, data manipulation and more.

It’s important to understand that this script works independently of any app or website already existing on the web server, working with event listeners and commands such as “fetch”, which resembles HTTP “Get/Post/Set” commands.

By listening for any network requests on the server, but being located as a .js file on the visitor’s device, the service worker will then manipulate those events with appropriate responses, depending on whether there’s internet or not, allowing for custom offline pages.

Furthermore, it’s possible to show custom content even if users are offline, based on their existing cache data. This set of data is even manipulative, meaning that we can code functions using the cache data as variables and parameters — if applicable to the respective project, of course.

Loading a website for the first time installs the service worker locally, and the service worker then creates a so-called app shell, containing cached data such as output pages, JSON content, CSS, images, scripts and so on.

This means that, while the first load might take a few seconds, subsequent loads utilizing the service worker will be significantly faster due to the sheer speed service workers deliver, and how they function by caching content.

Once these four requirements are implemented correctly, users on Android phones and other supported devices and browsers will be prompted to add the PWA to their home screen, where it will have an icon just like a regular app, and will open up in a browser.

It’s up to developers to make sure that the UI resembles the existing website or app, or perhaps to develop a new UI for the PWA users entirely. Total freedom in this regard is what has made some developers interested in this trend in the first place.

Pros and Cons of Progressive Web Apps

The pros of progressive web apps include the following:

• better speed and performance compared to websites
• security
• offline capabilities
• Add to Home Screen
• push notifications
• better bounce rates
• bridging the gap between mobile apps and websites
• feels like an app
• no App Store submissions/rejections.

There are some cons, though, including these:

• limited browser support
• limited native API access
• no App Store entries
• not all current PWAs use links for their page structure, building the PWA with tabs that are unlinkable and therefore undiscoverable by search engines.

Usage Scenarios

For certain types of websites and mobile applications, it would make sense to develop a PWA to act in situations where either the website or app doesn’t do the user justice.

It’s important to realize that while users can read news, add items to their cart while in offline mode and so forth, they’ll still need internet access to get new data, or to update their profile information or add an order.

PWAs can help keep this data stored for when the user gets reconnected, but in certain situations, such as paywall news sites, it might not be in the site’s interest to show this data when the user cannot click on any ads, or purchase a subscription etc.

Currently there are many different types of PWAs on the web. Some work as totally independent applications that just as well could have been developed as a native app, such as The Guardian’s RioRun.

Others have implemented service workers into their existing websites, adding offline capabilities through existing layers of websites — such as The Washington Post, where, if you browse their website and lose your connection, you can still read the article, and you’re presented with a specially coded offline page, offering a game of crosswords while you wait to get back online.

FlipKart has reported more than a 70% increase in conversions, AliExpress more than +104% in conversions for new users compared to their websites.

Konga, a Nigerian online retailer, has cut down their data usage by a reported 92%, meaning a huge improvement in page load times. For their userbase, which consists largely of people browsing from 2G networks, this has the potential to revolutionize the web in countries where data is costly and high speeds scarce.

Criticisms

Not everyone has been equally positive towards this trend. Jeremy Keith has voiced concerns over the fact that most of the current PWAs tend to hide their URLs to resemble native mobile applications, thereby disregarding one of the main benefits of the progressive web apps altogether — namely, the ability to index and search through crawled links.

Based on this criticism, Alex Russel, the man responsible for developing PWAs for Google, among other things, has said:

Like Jeremy, I’m agitated over the lack of access to URLs for PWAs launched in a more immersive mode. That seems to be the thing to be frustrated about if you care about URLs and sharing and it’s my concern too — so much so that our team prioritized fixing it this quarter.

Jeremy Keith also expresses concern over the fact that some PWAs don’t support desktop web browsers at all, only functioning on mobile phones, which is a valid point — but not directly related to PWAs themselves. After all, it’s up to the webmasters and app owners to dictate how well their different websites, apps and PWAs should integrate. He writes:

Looking at most of the examples of Progressive Web Apps, there’s an even more worrying trend than the return to m-dot subdomains. It looks like most of them are concentrating so hard on the “app” part that they’re forgetting about the “web” bit. That means they’re assuming that modern JavaScript is available everywhere.

It is puzzling that the time has been taken to develop a functional PWA, and then only release it for mobiles and not for the web as well. It seems odd that companies would exclude, knowingly, a certain portion of their visitors and users. Most of the sites I’ve been visiting have not shown any particular data that would not also be suited for the web, meaning that apart from the extra time to code for the web as well, I found no reasons not to.

Rounding Off

Progressive web apps have shown great results so far, with particularly great success in terms of conversion rates, bounce rates, and impressive performance increases. Coupled with the fact that website owners and businesses can produce a near app-like experience without the need for native development, this author believes the future looks bright for progressive web apps.

Almost any type of business would do well to implement service workers for the sole reason of cutting down load times significantly. Not every website needs offline functionality, and not every website is concerned about conversion or bounce rates. However, given the relative ease of setting up a simple system, I recommend that any serious website owner look into this emerging technology sooner rather than later.

I’d love to know what you think, though. Is it too early to be heading in this direction? Are things like hiding URLs and not being available everywhere against the very spirit of the web?

Frequently Asked Questions (FAQs) about Progressive Web Apps