1 מתוך 45

Progressive Web Apps

Reliable

2 מתוך 45

Going Offline

Users expect apps to start up on slow or flaky network connections, or even when offline. They expect the most recent content they’ve interacted with, like media tracks or tickets and itineraries, to be available and usable even if getting a request to your server is hard. When a request isn’t possible, they expect to be told there’s trouble instead of silently failing or crashing. And they expect to do it all quickly, with a recent study, Milliseconds Make Millions, showing that event a 0.1 second improvement in load times can improve conversion by up to 10%.

A reliable Progressive Web App is one that users can depend on and responds to their needs in blink of an eye.

Taking your PWA offline is a great way to make it reliable for varying network conditions and to speed up performance even when network conditions are great.

3 מתוך 45

How could an in-browser proxy help make your PWA work offline?

4 מתוך 45

Going Offline - The Key Players

Service Workers

In-browser proxy
Works online or offline

Cache Storage API

Manage browser’s site cache
Add/remove/delete/check for cache items

5 מתוך 45

Life of a Proxied Request

Browser

Server

Service Worker

Browser Cache

In order to start proxying requests through a Service Worker, it first needs to be installed! The first time a user comes to your PWA, that request will go directly to your server. After checking to see if the browser supports Service Workers, your PWA can register a Service Worker to act as a proxy. When loaded (fragment 2x), the Service Worker then sets up shop between your PWA and the server, allowing it to intercept requests for resources and, amongst other things, (fragment) control the browser’s cache through the Cache Storage API.

(fragment) When a request that’s covered by the Service Worker is made by the browser (including when it’s offline!), the Service Worker will intercept the request, acting like a proxy server! It can then decide if it should (fragment) request the resource from the cache via the Cache Storage API or (fragment) from the network. It then returns the resource (fragment) to the browser (fragment).

Service workers have their own lifecycle that dictates how they get installed, what they can proxy, when they are able to proxy requests, and when to update with a new version.

6 מתוך 45

Service Worker Scope - https://example.com/app/sw.js

URL	In-Scope	Reason
https://example.com/app	Yes	Matches root of scope
https://example.com/app/css/style.css	Yes	Is beneath root of scope
https://example.com/other-app	No	Above root of scope
https://example.com/js/shared.js	No	Above root of scope

7 מתוך 45

8 מתוך 45

Service Worker Update - https://example.com/app/sw.js

URL	Content Changed	Update	Reason
https://example.com/app/sw.js	No	No	No content changed,�same service worker path
https://example.com/app/sw.js	Yes	Yes	Content changed,�same service worker path
https://example.com/app/sw.12345.js	Yes	No	Different service worker path
https://example.com/js/sw.js	No	No	Different service worker path
https://example.com/js/sw.js	Yes	No	Different service worker path

Service Workers get updated when the browser detects that the actual Service Worker file is byte-different than the one currently controlling the client. Because of this, when updating a Service Worker, you should update the existing file without renaming it, including adding file hashes to the filename, otherwise the browser will never get the new version of your Service Worker! So! For each of the following, tell me if the service worker will or will not be updated and the reason why:

No, content didn’t change and the service worker is served from the same path
Yes, the content changed and the service worker is served from the same path
No, while the content changed, the service worker path also changed, so the changed content won’t be found
No, the service worker is being served from a different path
No, same as the third, while the content changed, the change in the service worker path means that change won’t be found

Instead of versioning the actual filename, it's considered a best practice to change the name of the cache (or differentiating the actual cache being used) instead. This will also prevent the old cache from being overwritten, which is still being used by the old Service Worker.

9 מתוך 45

10 מתוך 45

Service Workers &�Cache Storage API

Debugging with DevTools

11 מתוך 45

Application Panel - Service Workers

Opening up Chrome DevTools, you’ll see an Application panel. Clicking that panel gives you insight into a number of items that are otherwise hard to inspect about the currently running website. Here, the focus is on the Service Workers tab.

The Service Workers tab gives you a slew of information about the currently installed service worker. It’ll show you what clients are currently claimed by the service worker, the source of the service worker, its status, and let you test things like push and sync.

Here, if you have a Service Worker in the “waiting” state, you can skip skip the service worker’s waiting lifecycle by clicking skipWaiting. Doing so will immediately promote the waiting service worker to active. You’ll still need to reload the page to have it take over control, like the normal service worker lifecycle.

12 מתוך 45

Application Panel - Service Workers

13 מתוך 45

Application Panel - Service Workers

14 מתוך 45

Application Panel - Service Workers

There’s one more checkbox in this area, “Update on reload”. When this checkbox is checked, every navigation will refetch the service worker, install it as a new version even if it’s byte-identical, skip the waiting phase so the new service worker activates, and navigates to the page. In short, you’ll get the full Service Worker lifecycle for each navigation (including the refresh) without having to reload twice or close the tab.

While there are some uses for this setting, you should consider using it only as a last resort for debugging your service worker as it creates a different lifecycle than what your users will use and, like Bypass for network, is sticky between tabs and sites. Instead, you should consider using an Incognito mode tab to test fresh installs of your Service Worker, or the normal lifecycle with Skip Waiting instead.

15 מתוך 45

Try It Out - 15 Minutes

https://workshops.page.link/pwa03--going-offline

16 מתוך 45

Caching Strategies

17 מתוך 45

How might you cache frequently updated content? Infrequently updated?

18 מתוך 45

Caching Strategy - Stale-While-Revalidate

19 מתוך 45

Caching Strategy - Network First

20 מתוך 45

Caching Strategy - Cache First

21 מתוך 45

Caching Strategy - Cache Only

22 מתוך 45

Caching Strategy - Network Only

23 מתוך 45

Choosing a Strategy

How frequently is this updated?
Does this depend on something else?

There are two questions that you should ask yourself when trying to figure out the caching strategy to use for any given asset:

How frequently is this updated?
Does this depend on something else?

The answers to these questions can help narrow down how to manage your cache. For instance:

An item that’s frequently updated and doesn’t depend on something else, for instance home page content on a news site, should probably be cached with a Network First strategy
Items that are infrequently updated and have no dependencies, like like an interior article, should probably be cached with a Stale While Revalidate strategy
Items that are almost never updated and have no dependencies, like an image in an article, should probably be cached with a Cache First strategy.
On the other hand, if assets that are infrequently updated but have dependencies on each other, for instance shared JavaScript and CSS, you may want to cache with a Stale While Revalidate strategy but also cache the latest version when the Service Worker installs to ensure that they start using the same version and update together
.You may also have assets that are dependent on the Service Worker, like an offline fallback page. For these, you may want to cache with a Cache Only strategy and cache the latest version when the Service Worker installs, a pattern commonly known to as precaching.

24 מתוך 45

Working with Workbox

25 מתוך 45

Workbox - Setting Up Routing and Caching

import { registerRoute } from 'workbox-routing';

import { NetworkFirst } from 'workbox-strategies';

import { CacheableResponsePlugin } from 'workbox-cacheable-response';

26 מתוך 45

Workbox - Setting Up Routing and Caching

const pageStrategy = new NetworkFirst({

// Put all cached files in a cache named 'pages'

cacheName: 'pages',

plugins: [

// Ensure that only requests that result in a 200 status are cached

new CacheableResponsePlugin({

statuses: [200],

}),

],

});

27 מתוך 45

Workbox - Setting Up Routing and Caching

// Cache page navigations (html) with a Network First strategy

registerRoute(

// Check to see if the request is a navigation to a new page

({ request }) => request.mode === 'navigate',

// Use the strategy

pageStrategy

);

28 מתוך 45

Workbox - Offline Fallback

import { setCatchHandler } from 'workbox-routing';

// Warm the cache when the Service Worker installs

self.addEventListener('install', event => {

const files = ['/offline.html'];

event.waitUntil(

self.caches.open('offline-fallbacks')

.then(cache => cache.addAll(files))

);

});

29 מתוך 45

Workbox - Offline Fallback

// Respond with the fallback if a route throws an error

setCatchHandler(async (options) => {

const dest = options.request.destination;

const cache = await self.caches.open('offline-fallbacks');

if (dest === 'document') {

return (await cache.match('/offline.html')) || Response.error();

}

return Response.error();

});

30 מתוך 45

Workbox Recipes

import {

pageCache,

googleFontsCache,

offlineFallback,

} from 'workbox-recipes';

pageCache();

googleFontsCache();

offlineFallback({

pageFallback: '/offline.html'

});

31 מתוך 45

Try It Out - 15 Minutes

https://workshops.page.link/pwa03--workbox

32 מתוך 45

IndexedDB

33 מתוך 45

How do you think IndexedDB differs from Cache Storage?

34 מתוך 45

Cache Storage API

IndexedDB

Network resources
File-based content

Structured data
Searchable data

Both the Cache Storage API and IndexedDB provides asynchronous access to persistent storage for PWAs, both can be accessed from the main thread as well as web and service workers, and both play important roles in making them work reliable when the network is flakey or non-existent. But which should you rely on for what?

The Cache Storage API should be used for network resources, things you’d access by requesting them from a URL, like your HTML or HTML partials, CSS, and JavaScript. It should also be used for file-based content, like images, videos, and audio.
IndexedDB, on the other hand, should be used to store structured data, especially structured data that is generated client-side or frequently used, or data that needs to be searchable or combinable in an NoSQL-like manner, although it’s important to note that IndexedDB isn’t designed for full text search.

35 מתוך 45

Opening a Database

// Using https://github.com/jakearchibald/idb

import { openDB } from 'idb';

const db = openDB('bands', 1, {

upgrade(db, oldVersion, newVersion, transaction) {

// Switch over the oldVersion to allow the database to be incrementally upgraded. No `break` so all of the updates get run!

To start using IndexedDB, you first need to open a database. The first time you do this, you'll be creating the database. IndexedDB is an asynchronous API, but it has a callback interface instead of a Promise interface. While you don’t need any helper libraries to use it, this example uses Jake Archibald's idb library, which is a tiny, around 1.15k, Promise wrapper for IndexedDB. This example creates a database to hold bands and their band members.

To open a database:

First, use the openDB function to create a new IndexedDB database called bands. The version is set to 1. IndexedDB databases are versioned, so whenever you make changes to a database, you need to increase its version.
Second, an initialization object containing an upgrade function is passed to openDB. This function will be called when the database is installing for the first time, or upgrading to a newer version of the database. This is the only place where actions, like creating new Object Stores (you can think of them like tables) or indexes on object stores (that you’d like to search on), or data migration can happen.

36 מתוך 45

Opening a Database

switch(oldVersion) {

case: 0

// Placeholder to execute when database is first created (oldVersion is 0)

case 1:

// Create a store of objects

const store = db.createObjectStore('beatles', {

// The `name` property of the object will be the key.

keyPath: 'name'

});

// Create an store index called `age` based on the `age` key of objects in the store

store.createIndex('age', 'age');

}

});

37 מתוך 45

The “Beatles” Object Store

#	Key (Key path: “name”)	Value
0	John Lennon	{name: 'John Lennon', nickname: 'The smart one', age: 40, living: false}
1	Paul McCartney	{name: 'Paul McCartney', nickname: 'The cute one', age: 73, living: true}
2	Ringo Starr	{name: 'Ringo Starr', nickname: 'The funny one', age: 74, living: true}

38 מתוך 45

Getting an Item

// Using https://github.com/jakearchibald/idb

const tx = await db.transaction('beatles', 'read')

const store = tx.objectStore('beatles');

const value = await store.get('John Lennon');

39 מתוך 45

Getting an Item

// Using https://github.com/jakearchibald/idb

const george = {

name: 'George Harrison',

nickname: 'The shy one',

age: 58,

living: false

};

const tx = await db.transaction('beatles', 'readwrite');

const store = tx.objectStore('beatles');

store.add(george);

await tx.done

40 מתוך 45

The “Beatles” Object Store

#	Key (Key path: “name”)	Value
0	John Lennon	{name: 'John Lennon', nickname: 'The smart one', age: 40, living: false}
1	Paul McCartney	{name: 'Paul McCartney', nickname: 'The cute one', age: 73, living: true}
2	Ringo Starr	{name: 'Ringo Starr', nickname: 'The funny one', age: 74, living: true}
3	George Harrison	{name: 'George Harrison', nickname: 'The shy one', age: 58, living: false}

41 מתוך 45

Managing Storage

42 מתוך 45

Available Storage

if (navigator.storage && navigator.storage.estimate) {

const quota = await navigator.storage.estimate();

// quota.usage -> Number of bytes used.

// quota.quota -> Maximum number of bytes available.

const percentageUsed = (quota.usage / quota.quota) * 100;

console.log(`You've used ${percentageUsed}% of the available storage.`);

const remaining = quota.quota - quota.usage;

console.log(`You can write up to ${remaining} more bytes.`);

}

43 מתוך 45

Storage in the Applications Panel

44 מתוך 45

Try It Out - 15 Minutes

https://workshops.page.link/pwa03--indexeddb

45 מתוך 45

await tx.done;