Cache-busted scripts causing unnecessary load time

[snugglecactus]

The development cycle has been abysmal for me (e.g. 12 seconds between page reload and testing my game), due to files like `lang_mainsite.js` being cache-busted with `?[timestamp here]`. That file specifically can take 4 seconds to load by itself, and its loading begins ~6 seconds after the page reload (not good).

There's also `/data/themereleases/231110-1001/js/sveltec/dist/index.js` which takes 5 seconds to load and is 1 MB in size.

I would suggest not using timestamp-based cache-busting, and instead use a content hash in the filename, so the cache is only busted when the file is actually changed.

[GTSchemer]

That's very strange, I'm only seeing maybe 4 seconds even loading a huge project in Studio (using F5 rather than Ctrl-F5).

[snugglecactus]

Those numbers are for normal reloads, not hard reloads.

It's possible we're seeing different load times due to geographic location. You may be closer to the origin server (I'm in south Florida, United States). I wouldn't be surprised if BGA only runs a single instance of their development server. Of course, I don't know exactly what their server architecture is.

I tried testing with another browser, but am seeing similar load times. In my most recent test, the DOMContentLoaded event occurred 15 seconds after page navigation (i.e. reloading the browser tab) and the Load event occurred 51 seconds after.

[GTSchemer]

I am likewise in Florida, United States, using Firefox.

[GTSchemer]

For some reason I cannot get an event listener to work with DOMContentLoaded, but I did add a trace at the start of my Studio game's constructor, and a "load" event handler. It was less than 1 second between the two.

Is it possible you have a firewall, or a very large game asset?

[robinzig]

Regardless of precise load times (which can vary depending on network issues quality etc), I 100% agree with the OP that the timestamp-based query string for JS files on studio is ridiculous. I'd rather it had no "cache-bust" and you just had to manually ctrl-F5 after changes (you have to do that after changing CSS anyway - although as the OP says a query string based on a hash of the content is the best way).

The biggest issue for me is not being able to put breakpoints in and then have them hit after a refresh (which is often necessary for catching issues in setup code, amongst other things). Sure you can put a `debugger` JS statement in but that's annoying to have to do when for more sane development environments you can just put in a breakpoint in the browser developer tools and have it be remembered when you refresh the page.

[GTSchemer]

I think a required Ctrl-F5 would be very inefficient for large games since it causes a large load on the server, and a long load time.

I use a dedicated "Reload CSS" button for CSS.

[robinzig]

I think a required Ctrl-F5 would be very inefficient for large games since it causes a large load on the server, and a long load time.

I use a dedicated "Reload CSS" button for CSS.

OK sure (although this is only Studio we're talking about - games on the "real" BGA server seem to be able to update their CSS/JS when a new version is pushed without needing a hard-refresh). I wasn't saying that having to hard-refresh was great, just that I think it would be preferable to BGA deciding that JS should basically never be cached at all. But as the OP observed, and I agree with, there is a much better and fairly simple solution.