Board Game Arena

I recently did a redesign of the UI on my game, which involved extensive changes to the CSS. I playtested the game with friends before and after these changes. Some of the testers reported incorrectly rendered game displays, which was eventually tracked down to the fact that their browsers were using old cached versions of the CSS. This was seen on browsers running on different OSes, and of different browser families (mainly Mozilla/Firefox and Chrome).

In tracking this down, I noticed that the studio game server returns the following response header with the CSS file:
Cache-Control: max-age=2592000
This is a cache expiry of one month; the playtests were about 10 days apart. There is a valid concern that the browsers were not noticing that the CSS file was updated, but I am suspicious because the problem crossed browser families. I am wondering if having a cache age of one month is appropriate for materials served by the development server, where change is more frequent than in production. This would especially be the case for non-media files like the CSS and PHP files. In my opinion, a cache age of 3-5 days would probably be more appropriate.

Why not using ctrl+R (or similar combination for other browsers) for a hard refresh of the browser ?
I am always doing this after any js/css change and it works fine.

Forced browser refreshes didn't work. As I said, it is unclear why the browsers persisted in using the old CSS until their caches were cleared.

But isn't the whole point of hard refresh to clear the cache ?

Yes, but it's beside the point of my reason for posting here.

Yes it is. Studio is meant only for developpers, so when you are changing some assets, as a developper you know that you will need to hard refresh in order to make the changes. I don't see any good reason to change the cache expiry date on the studio.

Holding the shift key while clicking the refresh button works for me on Chrome.

Also (if using chrome/chromium/etc.) : https://imgur.com/a/acu9Xja

The behavior we saw was manifested even after browser hard refreshes (which are supposed to bypass the local cache, but for some reason did not). These are not technically naive people doing the testing.

RavingWanderer wrote: ↑06 July 2020, 14:31 The behavior we saw was manifested even after browser hard refreshes (which are supposed to bypass the local cache, but for some reason did not). These are not technically naive people doing the testing.

In this case, this should maybe be a bug report instead ?
Do you have any idea on how to reproduce this ?