Allow specifying a max age for the index page served by the Service Worker

Currently the Service Worker will serve the specified index file on navigation requests, checking for updates once the application has started.

While this does provide offline support & improves the TTI, one issue is that there’s no expiration date for said index file: a returning user who had visited the site two months back will effectively run a 2-months old version of the app. This is posing an issue for us as, in addition to requiring our API to remain backwards compatible for a long period, said user will not see new features / bug fixes until the next visit, possibly a few weeks after, causing slow upgrade cycles (as confirmed through our analytics)

There is currently not a straightforward way to handle that staleness issue:

• While the app does indeed know that a new version is available, showing an upgrade toast 30 seconds after loading a site one hasn’t been to in a month is just weird (e.g. https://github.com/angular/angular/issues/22080#issuecomment-408987881 mention that this was removed from angular.io). Similarly force-refreshing the user isn’t great either, especially as he/she can be in the middle of filling a form, since it takes a certain time for the SW to fetch the new app version.
• Preventing the Service Worker from serving navigation requests solves the freshness issue but breaks offline & degrades the TTI.
• Defining a dataGroup for the index file with a maxAge means the app shell hash isn’t checked anymore, which means the app version integrity isn’t guaranteed.

An intermediate solution could be to have a customizable maximum age for the app shell (index): if that max age (say a week) has been reached, the service worker would go to the network to re-fetch the shell. This effectively means that if a newer version of the app is available, all the new assets would have to be fetched for the app to load, losing the benefits of the SW background fetching. It would also break offline support for those users as well. However, frequently returning users would not experience that, and this would enforce a maximum staleness for the app.

There might be better ways to address the problem though, but the current situation of unlimited app cache duration isn’t ideal.

[angular-robot[bot]]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular’s feature request process in our documentation.

[laurentgoudet]

Thanks for the quick response.

doing a full page load on the next navigation (this is what angular.io does atm)

This is probably what I’m going to do for the time being, as doing so has a couple of benefits, namely the next version will be in cache, and the full page load can only be triggered versions older than a certain threshold. Interestingly I’ve never seen that happening on angular.io, or I just didn’t pay attention I guess.

In version 11, a new option will be available to always prefer the network for navigation requests. See here for more info. This should address many of the current limitations. I am leaving this issue open as a feature request for more fine-grained control (such as specifying a max age or a timeout).

Thanks for pointing that out. While this optimizes for freshness (while still providing offline support) at the expense of TTI, being able to specify a max age or a timeout at some point would indeed provide more control.