You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.