Closed FormularSumo closed 2 weeks ago
When the service worker isn't being used, Cache storage is never used, so it's not like Love.js is going out of its way to use it, and maybe there is a way I could stop it happening.
I should probably test with caching less/nothing in the service worker and seeing what happens.
For some reason screenshots are still being cached, but I'm not sure if I can do anything about that. I guess I could delete them on a fetch event like I used to with game.data but seems not so necessary here. Maybe they're just cached by the browser because it wants to, it's not like they're very big anyway or stored twice like game.data was. So I think it's fine to mark this issue as closed.
Slight problem, on Firefox it no longer wants to display the game's download progress, just "downloading game" until it finishes
Going to move the Firefox issue into a separate issue and keep this one closed.
Network Throttling profiles for reference
Chrome - 50/50 Mb, 0ms latency (custom) Firefox - 30/15 Mb, 2ms latency
After a new version of the game has been downloaded - or if a user has accessed it without any site data - the website somehow manages to save game.data to the site's caches, despite it not being one of the files my service worker tells it to cache and despite my service worker actively trying to delete it after caching the required files. The reason this data shouldn't be cached is that it is already cached by game.js in an indexedDB database, and so does not need to be cached twice.
As a workaround, I delete this unneeded cache when the service worker's fetch event is run - ie the next time the page is loaded. But that's not ideal as until the user performs a page load, the game is effectively downloaded twice on their device. According to Safari iOS it's apparently 3 times (in terms of space used) :thinking: Desktop Chrome storage used after first page access: