Progressive web app is an application that built and lives on the web, but will function more and more like a native application. It replaces all the functions of native apps and websites at once. Progressive web apps radically improve the quality of your end to end user experience. It is an app like experience on the web.

PWA over native app :

 Mobile is driving our lives into this revolution of native apps. We now use mobile devices more than desktop computers. Users often say apps are more predictable, easy to find on the home screen and featured push notifications that bring them back. But, there is a flip side to native apps usage. Users tend to install only a few apps in a year. The exposure of native apps in the app store is 0.01% because if you’re not in top of the app store your app will not get popularity, so finding your app in the app store is more difficult for the user. So, being in the App store is no major advantage. The main problem with native apps is that the user should search, download, install and open from the app store. But here, in progressive web apps they can use it immediately without any unnecessary installation and downloading just by adding the website to the home screen. You can have an icon and it gives an installed app like experience to the user.

Fundamental components in PWA :

Apps that were built based on the service worker and the web app manifest become known as PWA. Here, the main components are 

1. Manifest ( JSON file , focusing on background color, icons, screen ) 

2. Service worker (this allows push notifications, caching , file loading , backed sync )

Manifest File :

Manifest file is a configuration JSON file that contains the information from your progressive web app icon that appears on the home screen when it is installed. It contains the name of the app and background color here JSON file follows W3C specification with it . 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 that presents between the user’s tab and internet. The service workers function is to simplify the process of bringing an app offline and also have the app-like features such as push notification and backend sync. 

We can see the data that was retrieved is previous sessions of an app all this is possible by service workers and all this is done by event driven scripts. 

Here we can cache all static resources.

when the user has poor network connection then mainly opening time of the app and using the app is greatly reduced. 

Here, we have service workers that work like other web workers they run in a separate thread. They will not be tied to any specific tag

Example :

if your service worker present in http://app.com/main/index.js It will be able to intercept and take requests made to / main / or lower but, It will not intercept requests to the root http://app/. Because service workers will not depend on any other tab, they will handle the push notifications or background sync. 

If the new service worker script is detected, it will be updated automatically. 

It runs in a separate thread to your main page if a service worker present in /main/index.js It will affect /main/index.js and /main/header.jpg, but not, in /index.js solely . 

so, service workers will not intercept requests on the main page. 

This power enables me to provide cached responses to get pages to work when there is no data connection. 

Service workers will provide all the static information of an app to the user when the user has flaky network connection.

Precaching :

Here the caching pulls down requests before your website works out that they are needed. toolbox. precache([ ‘/index.html’,’/site.css’,’/images/logo.png’]);

Offline:

Whenever the user revisits the website and user have poor internet connection, then 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. So that they are offline available. It reacts fast and engages with the user here the startup time is more important app content is precached and browser is still in the device memory. So it works faster.

Push notifications:

 This is a great way to re engage with users bringing your app to the user’s mind frequently. If any unfinished transactions or receive alerts about relevant new content. Strength of the web app is URL: Installed web apps often hide the browser shell. There is no address bar for the user to share current URL. So, there is no use if you can’t share with anyone your app will not be promoted and exposed easily through any share. But, for progressive web apps we can share our app via either sharing buttons or a button to expose the URL here the URL has a unique web advantage. You can get people to use your app by clicking rather than by describing how to navigate it.

Properties for PWA:

  1. Responsive
  2. Offline
  3. Push notification
  4. Progressive
  5. Links
  6. Re Engage
  7. Installation
  8. Update
  9. Secure

Responsiveness:

Progressive web apps should aim primarily on phones and tablets and must respond to the screen sizes [ perfect 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 user can feel like they are still in the online mode.

Push notification :

The app should receive notification when the app is not running or give alerts to the user about any incomplete transactions that are present.

Progressive:

Apps still work as normal websites especially on platforms that do not yet support installation or service worker.

Links:

 App should not be locked in the browser or app store it should be deeply linked to and should provide methods of sharing current URL.

Re Engage:

Mobile app users are more likely to reuse their apps and progressive web apps are intended to achieve the same goals through push notification.

Installation:

 A PWA can 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 more user experience because all network requests can be intercepted through service workers. So apps should be hosted over HTTPS to prevent man-in-middle attacks.

How to build a progressive web application :

PWA uses progressive enhancement to load the most important content first, then add representational and functional extras as required it gives the users core experience as quickly as possible and the app can be converted to pwa by adding a few extra layers to it.

HTTPS:

SSL will be an extra layer of security to the web, helping the user to feel secure in site with pwa HTTPS is necessary for using service worker and allowing home screen installation.

APP SHELL:

Appshell is the first thing that a user sees. It should 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 loads. 

The example below is 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.

<!--index.html--> 
<body> 
<div id="root"> 
<div id="container">
<div class="inner-container"> 
<div id="header"> 
<img src="/assets/icon.png" alt="logo" /> 
<h1>Chat</h1> 
</div> 
<div id="loading-container"> 
<img src="/assets/icon.png" alt="logo" id="loader"/> 
</div> 
</div> 
</div> 
</div> 
</body> 
// index.js 
ReactDOM.render( 
<App />, 
document.getElementById('root') 
); 

Register a service worker:

Service worker you need here is push notification, caching, install prompt. First we have to check browser support service workers, then we can register. 

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.

<script> 
if ('serviceWorker' in navigator) { 
window.addEventListener('load', function() { 
navigator.serviceWorker.register('service-worker.js').then(function(registration) { // Registration was successful 
console.log('Registered!'); 
}, function(err) { 
// registration failed :( 
console.log('ServiceWorker registration failed: ', err); 
}).catch(function(err) { 
console.log(err); 
}); 
}); 
} else { 
console.log('service worker is not supported'); 
} 
</script> 
// service-worker.js 
self.addEventListener('install', function() { 
console.log('Install!'); 
}); 
self.addEventListener("activate", event => {
console.log('Activate!'); 
}); 
self.addEventListener('fetch', function(event) { 
console.log('Fetch!', event.request); }); 

Push notification:

Service worker allow your users to receive push notifications via the web push API Code:

navigator.serviceWorker.ready.then(function(registration) { 
if (!registration.pushManager) { 
alert('No push notifications support.'); 
return false; 
} 
//To subscribe `push notification` from push manager 
registration.pushManager.subscribe({ 
userVisibleOnly: true //Always show notification when received 
}) 
.then(function (subscription) { 
console.log('Subscribed.'); 
}) 
.catch(function (error) { 
console.log('Subscription error: ', error); 
}); 
}) 

Manifest file :

All we need here to install our application is manifest.json. We should add it in the application root directory. Here it indicates icons as a splash screen, a name and a description.

{ 
"short_name": "Chat", 
"name": "Chat", 
"icons": [ 
{ 
"src":"/assets/icon.png", 
"sizes": "192x192", 
"type": "image/png" 
} 
], 
"start_url": "/?utm_source=homescreen", 
"background_color": "#e05a47", 
"theme_color": "#e05a47", 
"display": "standalone" 
}

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.

window.addEventListener('beforeinstallprompt', e => { 
console.log('beforeinstallprompt Event fired'); 
e.preventDefault(); 
// Stash the event so it can be triggered later. 
this.deferredPrompt = e; 
return false; 
}); 
// When you want to trigger prompt: 
this.deferredPrompt.prompt(); 
this.deferredPrompt.userChoice.then(choice => { 
console.log(choice); 
}); 
this.deferredPrompt = null; 

Analyze your apps performance:

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

Use case :

Trivago, one of the latest and most significant shifts in tech is the rise of smartphones, especially in emerging markets. It’s already the case that more Trivago users access the 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, is a PWA. 

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