Proof of Concept: Add cache busting and auto-reloading to service workers

[ro-savage]

This is an attempt to address issue #2554 SWI3. Issues with service worker cache invalidation.

It also addresses SWI1 & SWI2 by auto reloading updated/different pages without user interaction.

To avoid confusion to the user, while the page is checking if the service worker is changed / exists, it displays a blank page.

Using the technique we damage a few of the advantages of PWA in return for 'easy of use' for developers and end users.

1. By default with PWA/SW, we can load the page instantly with the old/cached content. Using this technique, we must wait for a response from the server before showing the page. (Still works offline)

2. If we we find the page has changed, we do a force reload which means we've already hit the server once and waited for a response, and we then have to do the whole thing over again. If we'd just not used service workers we would have loaded the page faster.

This is just a POC. It is not a solid way to solve issues due to the issues above. Hopefully it might inspire some other ideas about how we could invalidate SWs and alternative ways to update the app without asking the user to refresh.

[sethbergman]

This looks excellent @ro-savage ! I've been testing your solution and it works perfectly! I've also been playing around with foreignFetch.

Is there anything pressing that you need eyes on? I've been getting more familiar with the intricacies of this project, and I can see that help is needed. I'd be happy to assist, and again great work! 🚀

[ro-savage]

Thanks @sethbergman

Its really just a POC. If you run with this, you may as well just remove PWA/SW.

What really needs to be done is probably a way to identify a service worker with some sort of id/version number internally. So that we can always fetch service-worker.js, check an id and know if we should re-render or just show whats already rendered.

Currently having to wait for a request to return, then if it fails, performance a full refresh isn't ideal. We end up making the site take significantly longer to load on a slow connection.

Happy to hear suggestions, if someone else has an idea. Or feel free to PR to my repo.

The goal isn't to be merged but hopefully inspire a different way / better way.

[jeffposnick]

Hello @ro-savage: I think #2440 (comment) applies here as well.

Moving away from some of the offline-first serving strategies means reintroducing network latency into the critical path of getting the page on the screen.

If the decision is made to move away from defaulting to the fastest offline-first experience, it would make more sense to me to just disable service worker registration by default rather ship a less-effective service worker.

[gaearon]

I agree with @jeffposnick here. The main purpose is to avoid latency, but that comes with tradeoffs. I guess we should just be more explicit about those tradeoffs (and maybe change the default), but this is giving us the worst of both worlds IMO. Appreciate the effort though!