4 ms·

I was refactoring a project serving user uploaded files yesterday, and had the occasion to test caching. Both Firefox and Chrome used ETag and If-None-Match pro

I was refactoring a project serving user uploaded files yesterday, and had the occasion to test caching. Both Firefox and Chrome used ETag and If-None-Match properly to check and cache queries. Which problems did you encounter? There was still one thing that surprised me a bit (but also makes sense). Images are fetched only once per page load in my testing. If an image with 60sec of cache is loaded, then removed by JS and added back after 2 minutes, then the browser will reuse the image from the initial load.

nikolayasdf123 2y ago
the issue I got was: 1) I (AWS CloudFront) supply ETag and If-None-Match header; I can see that header in responses. 2) browsers sometimes do respect that (once) I see 304 in responses, but 99% of the time they don't include ETag/If-None-Match in requests and thus I never get 304 responses (albeit AWS CloudFront, resource, data — nothing changed) and instead they perform some other caching and reload whole resource again with TTL that does not seem to come from my headers, totally disregarding ETags/If-None-Match logic. for videos it is even worse. unless you set `preload=none` in html, Safari, Firefox, Chrome will have all different policies trying to preload all videos on screen ignoring lazyload html tags. worse of all, caching does not work well, and videos will be attempted to be loaded almost every time and ETags/If-None-Match totally ignored.
- withinboredom 2y ago
  It sounds like you have caching disabled in your browser, either in dev-tools itself or through an extension. This is NOT normal behavior.
  - nikolayasdf123 2y ago
    the same happens for all browsers, Chrome, Safari, Firefox with default settings. but do agree this is not normal behavior :/ actually caching is happening, but it does not follow ETags or Caching policy headers that backends return, instead some in-browser internal caching policy being run
    - withinboredom 2y ago
      I’ve never seen the behavior you are describing. I would check that you’re sending the headers correctly: https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-control-headers/ https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-con... I’ve used that flowchart too many times.
      - nikolayasdf123 2y ago
        yep, I tried countless variations of this while testing. did not work! my conclusion in the end, this was intentional by browsers. they give priority to the their internal caching policies for performance or user-experience :/
        withinboredom 2y ago
        I don’t think this is true, as I rely on this behavior in an app. You must be doing something weird with your cache-control headers.

nikolayasdf123 2y ago

the issue I got was: 1) I (AWS CloudFront) supply ETag and If-None-Match header; I can see that header in responses. 2) browsers sometimes do respect that (once) I see 304 in responses, but 99% of the time they don't include ETag/If-None-Match in requests and thus I never get 304 responses (albeit AWS CloudFront, resource, data — nothing changed) and instead they perform some other caching and reload whole resource again with TTL that does not seem to come from my headers, totally disregarding ETags/If-None-Match logic. for videos it is even worse. unless you set `preload=none` in html, Safari, Firefox, Chrome will have all different policies trying to preload all videos on screen ignoring lazyload html tags. worse of all, caching does not work well, and videos will be attempted to be loaded almost every time and ETags/If-None-Match totally ignored.

withinboredom 2y ago
It sounds like you have caching disabled in your browser, either in dev-tools itself or through an extension. This is NOT normal behavior.
- nikolayasdf123 2y ago
  the same happens for all browsers, Chrome, Safari, Firefox with default settings. but do agree this is not normal behavior :/ actually caching is happening, but it does not follow ETags or Caching policy headers that backends return, instead some in-browser internal caching policy being run
  - withinboredom 2y ago
    I’ve never seen the behavior you are describing. I would check that you’re sending the headers correctly: https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-control-headers/ https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-con... I’ve used that flowchart too many times.
    - nikolayasdf123 2y ago
      yep, I tried countless variations of this while testing. did not work! my conclusion in the end, this was intentional by browsers. they give priority to the their internal caching policies for performance or user-experience :/
      - withinboredom 2y ago
        I don’t think this is true, as I rely on this behavior in an app. You must be doing something weird with your cache-control headers.