[leeoniya]

the bandwidth isnt the problem.

your browser still has to make the https connection to the cdn and request the file with a Last-Modified or Etag header so the server can return a 304 Not Modified response. This is the real cost, not the download size itself.

I'm not sure how often browsers choose to do this, but if you refresh a page, they all will.

[renke1]

There is also Cache-Control: immutable [1] which prevents browsers requesting the given file even when the site is refreshed. It's experimental though.

[1]: http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...

[manarth]

Currently only supported by Firefox (as of 49.0), according to Mozilla [1].

Interestingly, it's being used by the BBC [2], who have reported a 10.8% reduction in 304 responses as a result [3]. Google have also stated their intention to use it (comment 11 in the same Chromium ticket).

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

[2] https://mybbc.files.bbci.co.uk/notification-ui/2.6.8-mvt//sv...

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=611416

[renke1]

Another alternative would be service workers, which are (partially) supported by Chrome and Firefox according to [1]

[1]: http://caniuse.com/#feat=serviceworkers

[manarth]

In general, browsers shouldn't even revalidate the file as long as it's younger than the max-age lifespan.

They may choose to "evict" it from the cache, but that's generally based on a policy of recent usage and needing to free up/prioritise disk space for more recent assets.

I'm now interested to see how different browsers handle refresh/force-refresh - whether they revalidate a file that's still considered fresh, and whether they set request-headers to bypass upstream caches too. Maybe an experiment for the xmas holidays :-)

[leeoniya]

last time i tested this was a couple years ago.

i could not find a reliable way to make the 304 requests disappear using any available cache-related headers :/