796 reads

Progressive Web Application (PWA) — Complete Quickstart Guide

by BrainhubOctober 26th, 2018

Too Long; Didn't Read

The web has changed so much over the years. In the early 2000s, web pages resembled newspaper articles and encyclopedia entries, but throughout the decade, they evolved into more sophisticated blogs, video, and e-commerce sites.

People Mentioned

Companies Mentioned

featured image - Progressive Web Application (PWA) — Complete Quickstart Guide

With the advent of smartphones, more and more users started browsing the web on mobile devices. Mobile apps quickly surpassed websites in digital media usage. Companies shifted their attention from websites to apps, as apps allow them to provide more features and better engage with their users.

On the other hand, according to US Mobile App Report 2017, half of the smartphone users don’t install any new apps in a month.

The next big thing on the web, Progressive Web Applications, aims to combine the features of mobile apps with the accessibility, discoverability, and ease of use that have been the foundation of the modern Internet.

In this article, we’ll provide you with all the information you need to familiarize yourself with PWAs and point to resources that will help expand your knowledge allowing you to start developing PWAs today.

What are Progressive Web Applications?

Image source

Google defines Progressive Web Applications (PWA) as user experiences that have the reach of the web, and are:

Reliable — they should load regardless of network condition (i.e. offline or slow connection) and instantly show the user interface,
Fast — users should receive responses to their actions immediately (e.g. toggling a switch, typing in an input) and presented animations should be smooth,
Engaging — PWAs provide experience on par with native apps. Users can install them on their device, they have the ability to show custom icons and use device capabilities (e.g. push notifications, camera, bluetooth).

PWAs, rather than a set of technologies, are user experiences that focus on native-like behavior whilst maintaining the accessibility of the web platform.

PWAs aren’t limited to specific frameworks and can be built with any framework or none at all — when thinking about them try to think in terms of mindset, approach, design approach, rather than specific technologies, as in the end frameworks and APIs come and go while the ideas behind them are expanded upon.

Furthermore, PWAs are a natural progression of movement in web development. We’ve seen trends like:

rich Internet applications, which try to mimic the UX of desktop applications,
single page applications, which expand upon the previous concept using only web technologies (as opposed to browser plugins, e.g. Adobe Flash, Java, Silverlight)
responsive web design, which embraces the diversity of devices web pages are viewed on and sets its goal to provide the best experience on all of them while maintaining the single product,
JavaScript-based native app development using frameworks like Electron, Cordova, Ionic, React Native, which try to fuse together a web-based approach to user interfaces with native platform capabilities.

PWAs embrace the ever-rising expectations of the web platform and try to deliver them as best as possible.

Most agree that the barebones minimum to define a web application as a PWA is the capability to run offline (meaning that at least the app can be opened while offline) and the ability to be added to the home screen. It must be understood that simply adding those features doesn’t make the web app a PWA, as it may still lack the feel of a native app.

Progressive Web Applications — Core principles

Image source

#1 Reliability

Offline support

PWAs, when launched from the home screen, are expected to start regardless of network status. This can be achieved using Service Workers, which are client-side proxies written in JavaScript (technical documentation). Usually, for PWAs the following scenario occurs:

A user opens the application for the first time.
Client-side JavaScript code registers the Service Worker.
Service Worker fetches resources needed to display the web application and caches them.
The next time the application is opened, Service Worker intercepts network requests made by the browser to download resources needed to display the page (including initial server call for HTML file) and can respond with the cached version if necessary.

PWAs don’t have to display anything meaningful when the user is offline, simply displaying a message to the user that the network is down can be sufficient. Depending on the applications offline support could mean much more than that, e.g.:

news app could cache the most important articles or those that are relevant to the user whenever the app is opened and allow the user to read them whenever the connection is offline,
messaging app could store recent messages as they arrive and allow the user to browse them while offline.
collaborative spreadsheet app could store recent documents and allow users to view them and make changes that would be synchronized when the connection is brought back online.

As you can see, offline support is not limited to using Service Workers and starts at the design time when designers and product owners think about the application is offline.

Slow network conditions

PWAs are expected to work on slow network conditions. Navigation inside the app should be smooth regardless of bandwidth and latency as this would be the case for mobile apps. Again, Service Workers can help in such scenarios, e.g. by caching lazy-loaded routes. Additionally, when network resources are required to display resources, skeleton screens can be used to show an indication of progress.

#2 Performance

Performance is a very important metric of any web application. Google reports that:

Rail model

Performance engineers at Google have developed a universal model for measuring performance called RAIL. RAIL is a user-centric model that was created by researching human interactions with computer programs. Goals set by the RAIL model can be applied to any user-oriented software program, e.g. websites, mobile and desktop applications, and video games.

RAIL is an acronym that describes key performance metrics:

Respond — respond to user input in 100 ms,
Animate — animations should run in 60fps,
Idle — maximize idle time,
Load — display some content to a user under 1s and become interactive under 5s.

See RAIL model page for further description and some tips on how to achieve those goals. Familiarize yourself with critical rendering path.

PRPL pattern

Applying the PRPL pattern can greatly help in achieving the goals mentioned before.

PRPL stands for:

Push critical resources for the initial URL route.
Render initial route.
Pre-cache remaining routes.
Lazy-load and create remaining routes on demand.

Great examples of applying the PRPL pattern are the Polymer Shop and Preact CLI.

Performance measuring tools

Manual measurement:

Automatic checks:

Lighthouse can automate the process of performance testing and even run on CI servers,
Performance Budgets, e.g. Webpack has built-in tools to support this

#3 Engagement

PWAs should feel like native apps and have the capabilities of native apps.

On all major mobile platforms, PWAs can be installed on the user’s home screen and open without displaying any browser controls. On desktop platforms, PWAs can be added to taskbars and docks, shortcuts can be added to the desktop, however as of now they still open in a browser.

Web platform has grown very much and provides APIs for features like:

location services
camera,
push notifications,
native platform payments (e.g. Apple Pay, G Pay),
vibration,
bluetooth,
USB.

You can visit What web can do today? for a list of notable features available in modern browsers.

PWA implementation case studies

PWAs can greatly increase user engagement and conversion. Faster loading times and snappy interfaces yield longer and more engaging interactions impacting important metrics:

Pages per session, session length:

Twitter increased pages per session for Twitter by 65% and the number of tweets sent increased by 75%,
AliExpress increased pages visited by 100% and time spent per session increased by 74%,

Conversion rate:

AliExpress increased the conversion rate for new users by 104%,
Trivago increased their hotel offers click-out rate by 97%,
OLX increased click-through rate on ads by 146%. By using push notifications they saw 250% higher user re-engagement,
Treebo increased conversion rate 4 times,
Alibaba increased conversions by 76%.

Bounce rate:

OLX lowered their bounce rates by 80%.
Housing.com lowered their bounce rate by 40%.

PWA market analysis

Image source

#1 Apple vs Google

Apple lacks behind in PWA support. ServiceWorkers were introduced very late, currently doesn’t support manifests and doesn’t prompt users to add the app to the home screen. Most of the native APIs on iOS aren’t supported on Apple’s devices. Mobile Safari doesn’t support push notifications while desktop Safari has supported them from 2013 (albeit using proprietary standard rather than WHATWG’s).

On the other hand, Google actively promotes PWAs and focuses heavily on them. To understand the approach of the two technological giants, we must look at their sources of revenue.

Google focuses heavily on providing services to all devices while Apple focuses on their ecosystem. Apple Store has a very strict manual review process before approving the apps to the store and charges $100 per license to upload to the store, whereas Google is much more lax in terms of the review process, which is automated and licenses cost only $25.

Furthermore, Google in their effort to monopolize the market actively fought Windows mobile OS by excluding it from providing its services (both native apps weren’t provided on Windows Store and websites like Google Maps were using features not supported by the browser or were outright excluded like Hangouts).

It has recently invested 22 million dollars into KaiOS, the second largest operating system in India and actively develops applications based around web technology for that operating system.

Google is pressuring Apple into allowing PWAs into their ecosystem and thus weakening Apple’s supremacy in app store revenue (Google Play Store makes 10 times less revenue per device than the App Store).

#2 Emerging markets

PWAs can make a huge impact on the next billion users (the latest generation of internet users to come online on smartphones in places like Brazil, China, India, Indonesia, and Nigeria).

PWAs have the ability to surpass the native app market in those regions as they require 10x less data transfer to be used & installed (which can be a serious problem in some regions of the world, e.g. Kenya where users install mobile applications in internet cafes and 1 GB data plan costs $5 with average pay between $300–400), they are designed around connectivity issues.

Platform feature comparison

While the web platform has grown so much, it’s still missing support for basic capabilities of mobile apps on some devices.

Push Notifications are fully supported on Android, meaning that the app & browser can be closed and the device will still receive the notification. On desktop devices, browsers receive notifications only when they are open (the website can be closed but the browser has to be running), on iOS devices push notifications for browsers are not supported at all,
Background Location Services are not available to browsers, meaning you won’t be able to create an app that automates some tasks based on location (e.g. home control system),
Bluetooth, USB, NFC is only supported on Chrome browsers,
Device Authentication is currently under development and there is currently no way to authenticate and/or authorize users based on Fingerprint, TouchID, FaceID on the web.

While some key features might be missing, that doesn’t mean that the principles that PWAs should follow can’t be applied to native apps (especially those built using web technologies like React Native). Since PWAs are focused on providing great user experiences, any app can follow goals they set to achieve and appeal to users.