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

[laurentgoudet]

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. Configure service worker not to present stale content for frequently visited landing pages #22080 (comment) 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.

[gkalpak]

Thx for opening this feature request, @laurentgoudet. It definitely doesn't sound unreasonable 😃

There are work-arounds available as you mentioned and depending on the app, there are different update strategies to use (such as showing a notification, doing a full page load on the next in-app navigation (this is what angular.io does atm), or update on the next visit).

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).

[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.

[gkalpak]

BTW, while there are no immediate plans for working on this (so, no eta), if someone wants to try their hand at it, I would be happy to help/review.

[angular-robot]

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.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[henry-alakazhang]

I've had a go at a pull request in #49601 in the form of a global applicationMaxAge that expires entire app versions at a time. Happy to change the approach.