6 ms·

Same (but not a shopping site). Bundle the JS and CSS into one file each and cache it forever (hash in the filename to bust the cache). Then with each page tra

Same (but not a shopping site). Bundle the JS and CSS into one file each and cache it forever (hash in the filename to bust the cache). Then with each page transition there's exactly one HTTP request to fetch a small amount of HTML and it's done. So fast and simple.

mh-cx 2y ago
Exactly this. In our case we went so far to cache all static assets. Putting them into a directory with a hash in the name made them still easy to bust. # Cache static files location ~* \.(ico|css|js|gif|jpe?g|png|svg|woff|woff2)$ { expires 365d; add_header Pragma public; add_header Cache-Control "public"; proxy_pass http://127.0.0.1:9000; }
wmfiv 2y ago
This has been the common/best practice for so long I don't understand why TFA is proposing something different.
- youngtaff 2y ago
  Cache control directives indicate how long a browser, proxy etc can store a resource for… they don’t guarantee they will store it for that long though Control over Service Workers cache lifetime is more explicit I’d still specify ‘good’ cache lifetimes though
  - wmfiv 2y ago
    Makes sense as a theoretical problem. Have you ever seen data that suggests it's a practical problem? Seems like one could identify "should be cached forever but wasn't" using etag data in logs.
    - youngtaff 2y ago
      Facebook did a study about ten years or so back where they placed an image in the browser cache and then they checked how long it was available for… for something like 50% of users it had been evicted within 12hrs If one of the most popular sites on the web couldn’t keep a resource in cache for long then most other sites have no hope, and that’s before we consider that more people are on mobile these days and so have smaller browser caches than on desktop
      - jeeeb 2y ago
        From the discussion above it seems that browsers have changed their behaviour in the last 10 years based on that study. See: https://news.ycombinator.com/item?id=42166914 https://news.ycombinator.com/item?id=42166914
        youngtaff 2y ago
        Browsers have finite cache sizes… once they’re full the only way to make space to cache more is to evict something even if that entry is marked as immutable or cacheable for ten years
exceptione 2y ago
+ you need to pair that with immutable, otherwise you are still sending validation requests each reload time, so you are doing more than one HTTP request.

mh-cx 2y ago

Exactly this. In our case we went so far to cache all static assets. Putting them into a directory with a hash in the name made them still easy to bust. # Cache static files location ~* \.(ico|css|js|gif|jpe?g|png|svg|woff|woff2)$ { expires 365d; add_header Pragma public; add_header Cache-Control "public"; proxy_pass http://127.0.0.1:9000; }

wmfiv 2y ago

This has been the common/best practice for so long I don't understand why TFA is proposing something different.

youngtaff 2y ago
Cache control directives indicate how long a browser, proxy etc can store a resource for… they don’t guarantee they will store it for that long though Control over Service Workers cache lifetime is more explicit I’d still specify ‘good’ cache lifetimes though
- wmfiv 2y ago
  Makes sense as a theoretical problem. Have you ever seen data that suggests it's a practical problem? Seems like one could identify "should be cached forever but wasn't" using etag data in logs.
  - youngtaff 2y ago
    Facebook did a study about ten years or so back where they placed an image in the browser cache and then they checked how long it was available for… for something like 50% of users it had been evicted within 12hrs If one of the most popular sites on the web couldn’t keep a resource in cache for long then most other sites have no hope, and that’s before we consider that more people are on mobile these days and so have smaller browser caches than on desktop
    - jeeeb 2y ago
      From the discussion above it seems that browsers have changed their behaviour in the last 10 years based on that study. See: https://news.ycombinator.com/item?id=42166914 https://news.ycombinator.com/item?id=42166914
      - youngtaff 2y ago
        Browsers have finite cache sizes… once they’re full the only way to make space to cache more is to evict something even if that entry is marked as immutable or cacheable for ten years

exceptione 2y ago

+ you need to pair that with immutable, otherwise you are still sending validation requests each reload time, so you are doing more than one HTTP request.