INTRODUCTION

@DvdChavarri

@FranQuiJap

PWA, Introduction

They are experiences that combine the best of the web and the best of apps. They are useful to users from the very first visit in a browser tab, no install required.

As the user builds a relationship with these apps through repeat use, they make the candy shell even sweeter - loading very fast on slow network connections (thanks to service worker),

sending relevant Push Notifications and having a first-class icon on the user's home screen that can load them as fullscreen app experiences.

They can also take advantage of smart web app install banners.

Reliable

When launched from the user’s home screen, service workers enable a Progressive Web App to load instantly, regardless of the network state.

 

 

A service worker is like a client-side proxy, written in JavaScript

and puts you in control of the cache and how to respond to resource requests.

 

By pre-caching key resources you can eliminate the dependence on the network, ensuring an instant and reliable experience for your users.

Fast

53% of users will abandon a site if it takes longer than 3 seconds to load! And once loaded, they expect them to be fast, no janky scrolling or slow to respond interfaces.

Engaging

PWA are installable and live on the users home screen, without the need for an app store. They offer an immersive full screen experience with help from a web app manifest file and can even re-engage users with web push notifications.

 

The Web App Manifest allows you to control how your app appears and how it's launched. You can specify icons for the home screen and splash screen which is shown while the app is loading.

Which page is loaded when the app is launched, screen orientation, even whether to show the browser chrome or not.

Lighthouse is an open-source, automated tool for improving the quality of your web apps.

 

 

 

 

 

 

 

Lighthouse can be run as a Chrome Extension, from the command line, or used programmatically as a Node module. You give Lighthouse a URL that you want to audit, it runs a barrage of tests against the page, and then it generates a report on how well the page did. From here you can use the failing tests as indicators on what you can do to improve your app.

 

In 2015, designer Frances Berriman and Google Chrome engineer Alex Russell coined the term "Progressive Web Apps" to describe apps taking advantage of new features supported by modern browsers, including Service Workers and Web App Manifests, that let users upgrade web apps to be first-class applications in their native OS.

 

 

 

 

 

 

 

 

According to Google Developers, these characteristics are:

PWA History

• Progressive - Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
• Responsive - Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
• Connectivity independent - Service workers allow work offline, or on low quality networks.
• App-like - Feel like an app to the user with app-style interactions and navigation.
• Fresh - Always up-to-date thanks to the service worker update process.
• Safe - Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.

PWA Characteristics

 

• Discoverable - Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
• Re-engageable - Make re-engagement easy through features like push notifications.
• Installable - Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
• Linkable - Easily shared via a URL and do not require complex installation.

PWA Characteristics

PWA Checklist

To help teams create the best possible experiences we've put together this checklist which breaks down all the things we think it takes to be a Baseline PWA, and how to take that a step further with an Exemplary PWA by providing a more meaningful offline experience, reaching interactive even faster and taking care of many more important details.

1. Site is served over HTTPS

2. Pages are responsive on tablets & mobile devices

3. The start URL (at least) loads while offline

4. Metadata provided for Add to Home screen

5. First load fast even on 3G

6. Site works cross-browser

7. Page transitions don't feel like they block on the network

8. Each page has a URL

Baseline PWA Checklist

Exemplary PWA Checklist

1. Site's content is indexed by Google
2. Social metadata is provided where appropriate
3. Canonical URLs are provided when necessary
4. Pages use the History API

 

Indexability & social

Exemplary PWA Checklist

1. Content doesn't jump as the page loads
2. Pressing back from a detail page retains scroll position on the previous list page
3. When tapped, inputs aren't obscured by the on screen keyboard
4. Content is easily sharable from standalone or full screen mode
5. Site is responsive across phone, tablet and desktop screen sizes
6. Any app install prompts are not used excessively
7. The Add to Home Screen prompt is intercepted

 

User experience

Exemplary PWA Checklist

1. First load very fast even on 3G

 

Performance

Exemplary PWA Checklist

1. Site uses cache-first networking
2. Site appropriately informs the user when they're offline

 

Caching

Exemplary PWA Checklist

1. Provide context to the user about how notifications will be used
2. Site dims the screen when permission request is showing
3. Push notifications must be timely, precise and relevant
4. Provides controls to enable and disable notifications

 

Push Notifications

 

Progressive Web Apps  are an enhancement of existing web technology. As such, they do not require separate bundling or distribution.

 

Publication of a Progressive Web App is as it would be for any other web page. As of 2016, Progressive Web Apps are implemented in the Chrome browser, but more browsers may support the features needed in the future.

 

The technical baseline criteria for a site to be considered a Progressive Web App:

Technologies

• Originate from a Secure Origin. Served over TLS and green padlock displays (no active mixed content).
• Load while offline (even if only a custom offline page). By implication, this means that Progressive Web Apps require Service Workers.
• Reference a Web App Manifest with at least the four key properties: name, short_name, start_url, and display (with a value of standalone or fullscreen)
• An icon at least 144×144 large in png format. E.g.: "icons": [ { "src": "/images/icon-144.png", "sizes": "144x144", "type": "image/png" } ]

PWA Criteria

 

The web app manifest is a simple JSON file that gives you, the developer, the ability to control how your app appears to the user in the areas that they would expect to see apps (for example the mobile home screen), direct what the user can launch and more importantly how they can launch it.

Using the web app manifest, your web app can:

• Have a rich presence on the user's Android home screen
• Be launched in full-screen mode on Android with no URL bar
• Control the screen orientation for optimal viewing
• Define a "splash screen" launch experience and theme color for the site
• Track whether you're launched from the home screen or URL bar

PWA Manifest

 

{
  "name": "Weather",
  "short_name": "Weather",
  "icons": [{
    "src": "images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    }, {
      "src": "images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }],
  "start_url": "/index.html",
  "display": "standalone",
  "background_color": "#3E4EB8",
  "theme_color": "#2F3BA2"
}
 

Tell the browser about your manifest file
Now add the following line to the bottom of the <head> element in your index.html file:

<link rel="manifest" href="/manifest.json">
Best Practices
Place the manifest link on all your site's pages, so it will be retrieved by Chrome right when the user first visits, no matter what page they land on.
The short_name is preferred on Chrome and will be used if present over the name field.
Define icon sets for different density screens. Chrome will attempt to use the icon closest to 48dp, for example, 96px on a 2x device or 144px for a 3x device.
Remember to include an icon with a size that is sensible for a splash screen and don't forget to set the background_color.

Manifest.json:

Tell the browser about your manifest file
Now add the following line to the bottom of the <head> element in your index.html file:

<link rel="manifest" href="/manifest.json">

Service Workers

Service workers essentially act as proxy servers that sit between web applications, and the browser and network (when available). They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs.

Service Worker Api

 

1. Trigger and keep alive by the relationship to the events, not by the documents
2. Generic in nature
3. Event-driven with time limit scripting contexts and running at the origin
4. With natural endpoints for a wide range of runtime services
5. Have a state
6. With a script URL
7. Containing registration
8. Allocated ID or UUID
9. With lifecycle events
10. Have script resource map
11. Can skip waiting for the flags

 

Properties of Service Workers

• Work offline
• Capable of handling the push notification easily
• Synch the background data
• Capable of responding to the resource requests originate elsewhere
• Receive centralized updates
• Minimum size
• Share easily

Benefits of Service Workers

Is Service Worker ready?

 

An application shell (or app shell) architecture is one way to build a Progressive Web App that reliably and instantly loads on your users' screens, similar to what you see in native applications.

 

The app "shell" is the minimal HTML, CSS and JavaScript required to power the user interface and when cached offline can ensure instant, reliably good performance to users on repeat visits. This means the application shell is not loaded from the network every time the user visits. Only the necessary content is needed from the network.

 

App Shell Architecture

The app shell is similar to the bundle of code that you’d publish to an app store when building a native app. It is the skeleton of your UI and the core components necessary to get your app off the ground, but likely does not contain the data.

When to use the app shell model

Building a PWA does not mean starting from scratch. If you are building a modern single-page app, then you are probably using something similar to an app shell already whether you call it that or not. The details might vary a bit depending upon which libraries or frameworks you are using, but the concept itself is framework agnostic.

 

An application shell architecture makes the most sense for apps and sites with relatively unchanging navigation but changing content. A number of modern JavaScript frameworks and libraries already encourage splitting your application logic from its content, making this architecture more straightforward to apply. For a certain class of websites that only have static content you can still follow the same model but the site is 100% app shell.

Benefits

• Reliable performance that is consistently fast. Repeat visits are extremely quick. Static assets and the UI (e.g. HTML, JavaScript, images and CSS) are cached on the first visit so that they load instantly on repeat visits. Content may be cached on the first visit, but is typically loaded when it is needed.

• Native-like interactions. By adopting the app shell model, you can create experiences with instant, native-application-like navigation and interactions, complete with offline support.

• Economical use of data. Design for minimal data usage and be judicious in what you cache because listing files that are non-essential (large images that are not shown on every page, for instance) result in browsers downloading more data than is strictly necessary. Even though data is relatively cheap in western countries, this is not the case in emerging markets where connectivity is expensive and data is costly.

 

Requirements

The app shell should ideally:

 

• Load fast
• Use as little data as possible
• Use static assets from a local cache
• Separate content from navigation
• Retrieve and display page-specific content (HTML, JSON, etc.)
• Optionally, cache dynamic content

 

The app shell keeps your UI local and pulls in content dynamically through an API but does not sacrifice the linkability and discoverability of the web. The next time the user accesses your app, the latest version displays automatically. There is no need to download new versions before using it.

Web App Install Banners

Note: Add to Homescreen (sometimes abbreviated as A2HS) is another name for Web App Install Banners. The two terms are equivalent.

 

There are two types of app install banners: web app install banners and native app install banners. They let users quickly and seamlessly add your web or native app to their home screens without leaving the browser.

 

Adding app install banners is easy; Chrome handles most of the heavy lifting for you. You need to include a web app manifest file in your site with details about your app.

 

Chrome then uses a set of criteria and visit-frequency heuristics to determine when to show the banner.

What are the criteria?

Chrome automatically displays the banner when your app meets the following criteria:

• Has a web app manifest file with:
  • a short_name (used on the home screen)
  • a name (used in the banner)
  • a 144x144 png icon (the icon declarations must include a mime type of image/png)
  • a start_url that loads
• Has a service worker registered on your site.
• Is served over HTTPS (a requirement for using service worker).
• Is visited at least twice, with at least five minutes between visits.

Testing the app install banner

 

Once you've got your web app manifest set up, you'll want to validate that it's defined correctly. You've got two approaches at your disposal. One is manual, and the other is automated.

 

 

Testing the app install banner

 

To manually trigger the app install banner:

1. Open Chrome DevTools.
2. Go to the Application panel.
3. Go to the Manifest tab.
4. Click Add to homescreen, highlighted in red in the screenshot below.

Testing the app install banner

For automated testing of your app install banner, use Lighthouse.  You can run it as a Chrome Extension or as a NPM module. To test your app, you provide Lighthouse with a specific page to audit. Lighthouse runs a suite of audits against the page and then provides the page's results in a report.

 

The two suites of Lighthouse audits in the screenshot below represent all of the tests that your page needs to pass to display an app install banner.

Sources

• https://jakearchibald.com/2014/service-worker-first-draft/

• https://developers.google.com/web/fundamentals/getting-started/codelabs/your-first-pwapp/

• https://developers.google.com/web/fundamentals/getting-started/codelabs/debugging-service-workers/

• https://developers.google.com/web/fundamentals/getting-started/codelabs/offline/

• https://developers.google.com/web/fundamentals/getting-started/codelabs/push-notifications/

• https://developer.mozilla.org/es/docs/Web/Manifest

• https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=es-419#native