Cache resources to improve performance

[akivajgordon]

Resources (pages) should be cached in some way on the browser to improve performance of fetching new pages and to enable offline access.

[SLaks]

You can build this as a PWA to enable full offline support by caching both data and HTTP requests.

See https://developer.chrome.com/docs/workbox for a framework to help build this.

I am very interested in offline support; are you open to collaborating on a Pull Request for this?

[akivajgordon]

@SLaks Absolutely happy to get some help here. I'm not sure about this workbox thing. If it's a super easy integration, then it could be worthwhile, but otherwise I'd prefer to use the vanilla implementation as described on MDN (like this page: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation). I just prefer to keep dependencies to a minimum if possible.

In either case, let's keep the conversation going as I'm definitely interested in this feature.

[SLaks]

I wrote https://docs.google.com/document/d/1sOBZ3_9gZgGY7LkjhvXhpKTh6ul3G96MPgxEKs528R8/edit to specify exactly how this should work.

WDYT?

[akivajgordon]

@SLaks Wow that's a really comprehensive and impressive spec. I wish I'd seen it before I started implementing this in #118. Would you like to review that PR and point out any issues? I only spent like 20 minutes on it and it's mostly boilerplate.

In summary, it's a network-first approach, meaning it will always fetch unless that errors out (probably due to no network) in which case we'll use the cached files. The cache gets populated whenever files are fetched. Obviously this does not improve performance, but I haven't noticed performance problems in general, and as far as I know, I'm not hitting any bandwidth issues from GitHub Pages serving these files.

I'm sure this can be improved in the future, especially as it relates to clearing the cache and possible concerns of cache size, but I don't see the total size being too much of a problem at this point. For a first pass that only took a few minutes, this feels worth it to deploy, but I'd still be interested in your thoughts.

I also set up a simple manifest file.

[SLaks]

The problem with a simple cache-as-you-load approach is that if a user first scrolls down while offline, it will unexpectedly fail to load. This would be very unexpected for users who rely on the feature without understanding exactly how it works.

The primary point of cache-first fetching is for poor connectivity; for example, in tunnels, my phone will have very slow connectivity, but won't fail immediately. This would make a fetch-first Service Worker annoyingly slow for no good reason.

Should I start implementing my design?

I should probably also add an Offline Status icon in the titlebar (loading, ready, updating, please reload the page, or possibly Click to Install the Service Worker)

[SLaks]

Also, how do you feel about a build step to generate per-file version info?
I would implement it as a Node.js script run from the npm script.