Repository navigation
Allow specifying a max age for the index page served by the Service Worker #39266
Description
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
dataGroupfor the index file with amaxAgemeans 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.
Activity
gkalpak commentedon Oct 14, 2020
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 commentedon Oct 14, 2020
Thanks for the quick response.
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.
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 commentedon Oct 15, 2020
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 commentedon Jun 4, 2021
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 commentedon Jun 24, 2021
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 commentedon Mar 27, 2023
I've had a go at a pull request in #49601 in the form of a global
applicationMaxAgethat expires entire app versions at a time. Happy to change the approach.JeanMeche commentedon Aug 29, 2025
With #63364 we've announced that the service-worker package in now in maintenance mode and will not receive feature PRs and feature requests.
The message is also visible here: https://angular.dev/ecosystem/service-workers
angular-automatic-lock-bot commentedon Sep 29, 2025
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.