Not sorry to revive an old thread, but I heard something from a commenter on stack overflow that sounded relevant and I think it may be for you too. They asserted that the problem was better shown on a slow connection and when I activated network throttling (at least chrome supports this in the dev tools if you choose “response device mode”) and I can now see what you’re seeing.
What helped the other person was setting different caching headers on those files - then at least subsequent loads came from cache for your visitors (who aren’t running cacheless to debug things )
Normally we advise against changing your caching settings but in this case it may make sense for e.g. that file, AS LONG AS YOU ARE SURE IT WON’T CHANGE! That’s the major problem with changing cache settings: “oh, I’ll let it last a year.” <6 months pass> “oops, we got acquired, need to put a new logo in place but…oh, the old one is stuck in browser cache for another year for people who visited yesterday”.
So - I couldn’t quantify exactly where the problem was in my test, but it seems like you’ve quantified that, so I’d suggest posting your proposed header rules here so we can review them and make sure they are specific enough not to cause problems like that in the future. In fact I’d try it just on that header image to start with, so maybe that’s just this for your _headers file:
Would be a good starting test. If it works well you could expand it to e.g. all
/static/images/* files with the caveat that you’d want a NEW NAME for any files (such as splash.jpg) that you need to change later. That’s just a 2 day test but you can of course stretch it out as long as you feel comfortable once you’ve seen whether it makes an improvement.
Note that you CAN test headers like that in a deploy preview BEFORE going to production so very much recommended