Volvox CRAM being slow on our AWS website for confusing reasons

[cmdcolin]

i am seeing in firefox that on current main there are hundreds of requests for the same cram file range being made, and this also slows it down significantly.

current main

visiting https://jbrowse.org/code/jb2/main/?config=test_data%2Fvolvox%2Fconfig.json&session=share-hgUR6_HHBR&password=69zNb

273 requests made, many repeated for .cram file and .2bit file. ~41 seconds to load the track, firefox 130

v2.15.0

visiting https://jbrowse.org/code/jb2/v2.15.0/?config=test_data%2Fvolvox%2Fconfig.json&session=share-hgUR6_HHBR&password=69zNb

5 seconds to load, just one request for cram file and 2bit file

the MYSTERY: manually building v2.15.0, aws sync'ing it to a new folder, and building is slow again??

I checked out v2.15.0, uploaded to aws s3 bucket, and visited here

https://jbrowse.org/demos/slowcramrepro/v2.15.0/?config=test_data%2Fvolvox%2Fconfig.json&session=share-hgUR6_HHBR&password=69zNb

and it is mysteriously slow. i don't get necessarily know what is going on and so i'm not sure if there is some factor of the issue being

a) the mystery build i made is wrong, and it is a bug between v2.15.0 and main
b) my browser on my computer is confused, and acting weird, and it's not related to any change in jbrowse
c) aws created a change, where new files uploaded are now treated differently and not cached the same after some recent date or something else like this
d) something totally different(???)

if anyone else can confirm the above observations let me know

[cmdcolin]

also note: i am not sure if i can reproduce this observation in chrome, might be firefox only

[cmdcolin]

note also: this effect seems a bit AWS specific, can't really reproduce locally AFAIK

[cmdcolin]

@garrettjstevens reported not seeing this in either chrome or firefox on latest main

[cmdcolin]

i'll just close this for now. unless i can get confirmation it's not just me and firefox being weird, seems unneeded to track it here.

i made a x-ref issue at GMOD/cram-js#140 to track the larger issue of aggregating requests in cram-js in a built-in way