Use FetchEvent.waitUntil() for cache expiration logic

[jeffposnick]

Right now, the logic for cache expiration (if enabled) is started asynchronously in the onfetch handler following the call to FetchEvent.respondWith().

This ensures that the controlled page gets the response without being blocked during the time it takes for the cache expiration logic to run. Unfortunately, there's the possibility that the browser will terminate the service worker before the cache expiration logic has a chance to complete.

This is not likely in the current Chrome implementation at least (which tends to keep the service worker running following a fetch event for at least a few seconds), but it would be ideal to specifically tell the service worker to stay alive while the cache expiration code runs.

w3c/ServiceWorker#584 tracks FetchEvent.waitUntil(), which looks like will make it to browsers at some point. Another related bug is w3c/ServiceWorker#679

[wibblymat]

I was thinking about this, and I'm just going to make some vague notes here for future reference.

It's better to run the clean up logic once for a batch of requests, rather than for each request separately. So rather than having a promise for the clean up passed to waitUntil, have a promise for a simple setTimeout of, say, 10 seconds, which then looks at a queue of pending tasks and resolves once they are all performed. Because waitUntil will keep the service worker alive we can keep the task list in memory rather than serializing to indexedDB, etc.

We then also keep a total of pending timeouts. If, when the timeout is over, there are more timeouts still pending then don't process the task queue at all. Only when we know that there may be no more opportunities do we process the queue, to keep the number of times the logic is run to a minimum.

Hmm, except that this might mean that it doesn't run for a very long time on a site that makes frequent requests, so maybe also look at the age of the oldest task in the queue and make sure they don't get to older than, say, 1 minute.

Once this is actually implemented in browsers we can check things like how long a waitUntil gets before being killed, what the real performance gains might be before implementing, etc. I just didn't want to forget the idea.

[jeffposnick]

All good points. For now, it's ¯\_(ツ)_/¯ and we'll have to see what the performance and reliability implications are of different approaches when the underlying waitUntil() is there.

[jeffposnick]

See also: w3c/ServiceWorker#790

[wanderview]

w3c/ServiceWorker#584 tracks FetchEvent.waitUntil(), which looks like will make it to browsers at some point.

FWIW, FetchEvent.waitUntil() is in Chrome and will be in the first version of SW's shipped in Firefox release.

You just have to call it synchronously in the event handler at the moment. This makes it a bit ugly to use, but doable. Something like this:

https://github.com/wanderview/wanderview.github.com/blob/master/sw.js#L54

[wibblymat]

waitUntil in Chrome was fixed today, will presumably ship in 53.

Seems like it shipped in FF in 44.