The intention was that every GET the app sends via fetch would be cached, that includes SvelteKit routes, several Firebase calls, Mapbox tiles, ... but to prevent stale cache problems, these caches would only be used in case of a fetch error on assumed network loss.
309 would also be helpful, because static pages like the rules page or homepage that don't critically depend on Firebase being logged/in should überhaupt not be blocked to load offline by Firebase support. They could easily be cached by a service worker when SSR is enabled.
Map tiles could be cached by a service worker, but we need to understand what to cache. Care needs to be taken that these should caches also expire at some point.
See this commit https://github.com/WelcometoMyGarden/welcometomygarden/commit/e750fb3f6994116382c8a51183f054b0e2781321
So we were storing up to hundreds of MBs on user's browsers without providing any offline functionality for it.
It is possible though, and could be useful for:
But much more thought needs to go into this:
309 would also be helpful, because static pages like the rules page or homepage that don't critically depend on Firebase being logged/in should überhaupt not be blocked to load offline by Firebase support. They could easily be cached by a service worker when SSR is enabled.