Make whatwg.org and spec.whatwg.org available offline via a service worker

[domenic]

I don't think going "full PWA" with a manifest is worthwhile since currently only Chrome uses the manifest and it requires hiding the address bar to get any benefits. (See previous discussions in whatwg/streams#637.)

But a service worker at least would be nice.

[domenic]

/cc @jakearchibald

I started working on this and am not sure what to choose for our caching strategy. Referring to Jake's blog I am unsure between:

1. Cache only
2. Cache, falling back to network
3. Cache and network race
4. Cache then network (basically, stale-while-revalidate)

(1)-(3) only work if we are diligent about updating the cache key (and thus blowing away all of the cache, I guess) every time we edit the site. I suppose the build process could do that?

(3) is potentially faster on devices with very slow hard drives (certain mobile phones)

(4) seems easiest but potentially wastes some user bandwidth.

I could imagine a (5) where we have a different cache key for every Git revision and the build process writes out a mapping of last-updated-at revisions -> URLs so that we automatically refresh the cache for changed files but not ones we know haven't changed. Very complicated.

I'll go with (4) unless people have thoughts.

My second question is whether we waitUntil we cache all resources at install time, or only wait for the main page's resources. I'll go with all resources since there's not that many and that's simplest, but again welcome thoughts.

[jakearchibald]

I'd think of the site as having two categories of resource:

1. Application resources. Stuff that's used across multiple pages, such as the CSS, any images/fonts needed by the CSS, any JS, and perhaps an offline-fallback page. Basically, the kind of things you'd bundle with the package if it were a native app.
2. Content resources. Page content, including any images used by the pages.

For 1, the resources would ideally have immutable URLs. I'd create a versioned "static" cache and add them during the install event of the service worker. If the URLs are immutable, you can create the cache version using a hash of the URLs. These resources would be served cache-only.

For 2, these can be lazily fetched and cached as the user browses the site. Online-first is a reasonable first step here, but the ideal would be https://developers.google.com/web/updates/2017/02/navigation-preload, where the network & cache race, but if the cache wins notify the user if updated content is found. This shouldn't be a bandwidth concern, as you're using less data than without a SW. If the content doesn't change frequently than 304 helps.

[domenic]

Hmm. So, we've historically not wanted to add the complexity of immutable URLs. If we aren't willing to tackle that, does that change your thoughts? I guess maybe cache-only is still doable using a scheme similar to my (5).

I think it's a nice feature of #202 that the moment you visit any page on whatwg.org, you can then go offline and browse the whole site. (Well, modulo the fact that we've actually spread the site out among several different origins...) Your lazily-fetched-and-cached suggestion removes that property, but is more respectful of the user's bandwidth, I suppose.

The point about offline-first vs. notify-about-updated-content is interesting... In #202 you'll basically have to hit reload, or at least navigate to a page twice, to see updated content. I guess that is a bit sad, but it's the price to pay for instant loading. Adding a notification could definitely help ameliorate that... And I guess it's not too much work...

[jakearchibald]

Hmm. So, we've historically not wanted to add the complexity of immutable URLs. If we aren't willing to tackle that, does that change your thoughts?

It should be fine. The CSS etc can still be cached in the install step, and the server can 304 if it hasn't changed. It just means you'll need to manually change the content of the service worker if you update one of those assets. As you said, the git commit hash would work.

I think it's a nice feature of #202 that the moment you visit any page on whatwg.org, you can then go offline and browse the whole site. (Well, modulo the fact that we've actually spread the site out among several different origins...) Your lazily-fetched-and-cached suggestion removes that property, but is more respectful of the user's bandwidth, I suppose.

If the content is small enough it's ok (which is the case here I think).