Blog
BLOG

The path to the next web: Progressive web apps

Veera Raghava Naram
   

As the web experience evolves, businesses should prepare now to deliver the next new online experience as they progress from Web 2.0 to Web 3.0. Progressive web applications (PWAs) have emerged to provide responsive browser experience and have the ability to work seamlessly anywhere, anytime, on any device.

PWAs are built on the web, lives on the web, but functions more and more like a native application. It replaces all the functions of native apps and websites at once. To put it simply, progressive web apps create an app-like experience on the web and radically improves the quality of the end-to-end user experience.

PWA over native apps

Thanks to a surfeit of mobile devices around us, native apps are the primary choice for today’s users. These apps are more predictable, easy to find on the home screen, and features push notifications that bring users back.

However, there is a flip side to native apps usage as well. Users tend to install only a few apps in a year. Moreover, the exposure of native apps in any app store is 0.01%, which means users need to search for and find the app. If an app is not on top of the app store, searchability becomes difficult. So, being in the app store is no major advantage for native apps. Another issue is, native apps need to be downloaded, installed and opened from the app store itself. In the case of progressive web apps, users can use them immediately without any unnecessary installation and downloading — just by adding the website to the home screen, which gives an installed-app-like experience to the user.

Take a look at Trivago, a technology company specializing in internet-related services and products in the hotel, lodging and metasearch fields. For them, one of the latest and most significant shifts in tech was the rise of smartphones, especially in emerging markets. Already most Trivago users access its service on mobile than on desktop computers. So, the move to dive into the deep end of mobile was a no-brainer for Trivago. Once Trivago set their sights on mobile, the next question was: “What’s the best mobile tech out there to reach as many people as possible while providing a fast, seamless experience?” The answer, as Trivago found, was a PWA.

The PWA itself is nothing short of impressive when you consider its functionality, Lighthouse scores, and overall user experience. The Trivago PWA lets users browse and book travel arrangements — just like their native app — but with the ease and speed of a website. From a usability standpoint, they chose to keep the same look and feel as their website, which is a smart move as it helps users who are already familiar with the site navigate and book very easily.

Fundamental components in PWA

PWAs, when built based on the service worker and manifest components, allows scripts to run in the background and provides better user experience.

  • Manifest (a JSON file, focusing on background color, icons, screen)
  • Service worker (this allows push notifications, caching, file loading, backed sync)

Let’s take a look at these in detail.

Manifest file

Manifest file is a configuration JSON file that contains the information from aprogressive web app icon that appears on the home screen when it is installed. It contains the name of the app and background color. Here the JSON file follows W3C specifications. It is possible to run the web app in full-screen mode as a standalone application to assign an icon that will get displayed on the device.

Service worker

Service worker is a proxy between the user’s mobile device and the Internet. The service worker’s function is to simplify the process of bringing an app offline and also to have app-like features such as push notification and backend sync.

Through event-driven scripts, service workers enable users to see that the retrieved data is previous sessions of an app.

Here, we can cache all static resources, like mentioned in the image below.

When the user has poor network connection, the opening time of the app and usage of the app is greatly reduced. Another feature of service workers is that they run in a separate thread like other web workers, without being tied to any specific tag.

Let’s take a look at an example.

If the service worker is present in http://app.com/main/index.js, it intercepts and takes requests made to / main / or lower, but does not intercept requests to the root http://app/. Since service workers don’t depend on any other tab, they handle the push notifications or background sync. If the new service worker script is detected, it is updated automatically.

It runs in a separate thread to an user’s main page. If a service worker is present in /main/index.js, it affects /main/index.js and /main/header.jpg, but not in /index.js solely.
So, service workers don’t intercept requests on the main page. This enables users to provide cached responses to get pages to work when there is no data connection. In fact, service workers provide all static information of an app to the user in case of flaky network connections.

Precaching

Precaching has the ability to save respective files to the cache during the installation of a service worker. Here, the caching pulls down requests before the website works out that they are needed. (for example, toolbox. precache([ ‘/index.html’,’/site.css’,’/images/logo.png’]))

Offline

Whenever the user revisits the website while on a poor Internet connection, the offline mode initial static aspects are precached.

This downloads and catches them, when the service worker is installed. This means they don’t need to load from the server when they require it. By default, the requests are freshly sourced from the network. If the network connection is poor, it fails to cache but makes it available offline. It reacts and engages with the user faster, since the app content is precached and the browser is still in the device memory.

Push notifications

This is a great way to re-engage with users by bringing the app to the user’s attention frequently, in case of any unfinished transactions or relevant new content. The strength of a web app is the URL: Installed web apps often hide the browser shell. There is no address bar for the user to share the current URL. So, there is no use if it is not shared with anyone. The app will not be promoted and will be exposed easily through any share. But, for progressive web apps, a user can share the app either via sharing buttons or a button to expose the URL. Here, the URL has a unique web advantage. You can get people to use the app by clicking rather than by describing how to navigate it.

Properties of PWA

  • Responsiveness: Progressive web apps should be aimed primarily on phones and tablets, and must respond to the screen sizes (perfectly filling screen). They should also just work as desktop websites.
  • Offline: The app should be started offline, and should display some useful information to the user without displaying any blank or ‘no network connection’ pages so that the user can feel they are still in the online mode.
  • Re-engage: The app should receive notifications when the app is not running. It should send alerts to the user about any incomplete transactions. Mobile app users are more likely to reuse their apps. PWAs are intended to achieve the same goals through push notifications.
  • Progressive nature: PWAs should work as normal websites especially on platforms that do not yet support installation or service workers.
  • Links: These apps should not be locked in the browser or app store; they should be deeply linked to, and should provide methods of sharing, the current URL.
  • Installation: A PWA should be installed on the device home screen making it readily available.
  • Update: When new content is published and the user is connected to the Internet, the content should be made available in the app.
  • Secure: PWA has a better user experience because all network requests can be intercepted through service workers. So, apps should be hosted over HTTPS to prevent man-in-the-middle attacks.

How to build a progressive web application

In a site with PWA, SSL provides an extra layer of security to the web to make the user feel secure. HTTPS is necessary for using service workers and allowing home screen installation. The following are the steps that go into building a PWA.

App shell

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

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

Register a service worker

The service worker that is needed here is push notification, caching and install prompt. Before registering it, the browser support service worker needs to be checked.

The service worker file here has 3 life cycle events:

  • Install when user first visits page
  • Activate before registration completes
  • Fetch when an application makes a network request

Push notification

The service worker allows users to receive push notifications via the web push API Code:

Manifest file

All one needs here to install the application is manifest.json. Indicated by a splash screen, a name and a description, it needs to be added to the application root directory.

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 the homescreen.

Analyze your app’s performance

The most important thing for PWA is performance. The app should be fast for users on all network conditions. Caching and offline capability will do miracles here, but the application should be fast and speedy.

Comment

Your email address will not be published. Required fields are marked *