PWA: Add method for visitors to save pages for offline viewing

[ryelle]

See https://chrisruppel.com/blog/service-worker-offline-content/

Currently all visited pages are cached (or they should be), up to 50 pages, but the user has no control over which specific pages are cached. We could add a "Save for offline viewing" button to allow users to intentionally download some content. It should probably use a separate cache bucket than the navigation cache so navigation doesn't knock out valid entries, and we should maybe disable the navigation cache to reduce duplicate cached entries.

Could also improve the offline view by listing out available content (or later attempt by same author).

[westonruter]

Having a user-initiated Save Offline feature is something we considered demonstrating for the PWA plugin, but we haven't yet done so.

It's much easier to just cache a page that a user visits, since runtime caching will pick up all the assets that are referenced on the page. One workaround for that would be to load the page in a hidden iframe, which is what Surma did in his Progressive WordPress proof of concept:

https://github.com/GoogleChromeLabs/ProgressiveWordPress/blob/b4412c8ac24023bece93e6326001e4b311faa0e3/src/theme/scripts/offline-articles.js#L71-L87

Two complications for the iframe are (1) the viewport size should be the same as the current browser window to ensure the srcset images are loaded, and (2) lazy-loading must be disabled for that request.

I suppose there are three use cases here for the content being offline:

1. I visited an article and I want to go back to finish reading it, while I'm offline.
2. I'm viewing an article, and I'm about to go offline, so I want to make sure it continues to be accessible.
3. I see a list of articles that I want to read, and so I want to mark them for offline-reading before I go offline.

The first use case is simpler, as there's nothing the user has to do, there's no UI to incorporate into the theme, and there's no technical complications (the service worker just has to add the responses to the runtime cache).

The second use case is more difficult, since you have to proactively iterate over all assets to include in the cache. As opposed to iterating over the DOM as suggested in that article, you can instead use window.performance.getEntriesByType('resource') to gather a list of all resources that have been requested on the page, as shown in the Workbox.js docs: Send the service worker a list of URLs to cache. This is being considered for the PWA plugin to ensure the assets on the initial page are added to the runtime cache, after the service worker is installed: GoogleChromeLabs/pwa-wp#180

Could also improve the offline view by listing out available content

This is something I was planning to prototype with the PWA plugin when I got a chance. In addition to querying all cached pages in the Cache API, I think the actual titles of the pages should be able to be extracted by reading the body and pulling out /<title>(.+?)<\/title>/.