6 ms·

I wonder why the article doesn't mention utilizing the browser cache for your static CSS and JS assets instead of introducing a service worker as first measure.

by mh-cx 2y ago

I wonder why the article doesn't mention utilizing the browser cache for your static CSS and JS assets instead of introducing a service worker as first measure. Few years ago I built a shopping site MPA this way and the page transitions were almost not noticable.

jdsleppy 2y ago
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.
thangngoc89 2y ago
Edit: below isn’t true. You could set immutable in cache header and the browser wouldn’t verify. —— Original comment: With browser cache, the browser stills need to send a HEAD request to see if the content was modified. These requests are noticeable when networks are spotty (train, weak mobile signals…) Service Worker could cache the request and skip the head requests all together
- 01HNNWZ0MV43FF 2y ago
  Not if you tell the browser it's guaranteed fresh for 10 minutes and then use cache-busting in the URL
  - thangngoc89 2y ago
    Oh yeah. The immutable tag right? Total forgot about that
- cuu508 2y ago
  Set max-age in the Cache-Control header to a high value and the browser will not need to revalidate. When deploying a new version, "invalidate" the browser cache by using a different filename.
  - austin-cheney 2y ago
    Or keep the file name and send the file with a query string of some changed numeric value
palsecam 2y ago
Especially since the `stale-while-revalidate` and `immutable` Cache-Control directives are well supported nowadays. Stale-while-revalidate: see https://web.dev/articles/stale-while-revalidate https://web.dev/articles/stale-while-revalidate & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#stale-while-revalidate https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... Immutable: https://datatracker.ietf.org/doc/html/rfc8246 https://datatracker.ietf.org/doc/html/rfc8246 & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... And if using a CDN, `s-maxage` (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#s-maxage https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...) is quite useful. Set it to a long time, and purge the CDN cache on deploy.
- exceptione 2y ago
  Immutable is what you need. Crazy enough, Chrome has not implemented it. Bug open since 2016: https://issues.chromium.org/issues/41253661 https://issues.chromium.org/issues/41253661 ------------------ EDIT: appears that Chrome suddenly had decided in 2017 to not validate at all on reload anymore, after Facebook had complained to Chrome devs about Chrome being more a drag on their servers compared to other browsers.
  - palsecam 2y ago
    To be fair, it’s because Chrome handling of a soft reload is different from Firefox or Safari, and does not lead to revalidating (let alone refetching) assets files. See https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html https://blog.chromium.org/2017/01/reload-reloaded-faster-and... Quoting https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/ https://engineering.fb.com/2017/01/26/web/this-browser-tweak...: > We began to discuss changing the behavior of the reload button with the Chrome team. […] we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones. > Firefox was quick in implementing the cache-control: immutable change and rolled it out just around when Chrome was fully launching their final fixes to reload. > Chrome and Firefox’s measures have effectively eliminated revalidation requests to us from modern version of those browsers.
henriquegogo 2y ago
I was just wondering the same. Browser cache is is old and effective, but unfortunately nobody cares nowadays.
- leptons 2y ago
  People care when the browser cache is holding on to something - "try clearing your cache" is still a very common tech support solution.
Onavo 2y ago
Because cache invalidation is one of the two hardest problems in computer science.
youngtaff 2y ago
On a session basis browser caches are effective but on a session to session basis it’s likely the content will get evicted as resources from other sites gets cached - there’s an oldish Facebook study where they placed an image in the cache and after 12hrs it had been evicted for 50% of visitors Service Workers offer more controls over cache lifetime, and in Chromium (at least) JS gets stored in an intermediate form (which reduces the re-compile overhead on reuse)
VoodooJuJu 2y ago
Well that would just make it too simple and not blog-worthy.

by mh-cx 2y ago

jdsleppy 2y ago

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.

thangngoc89 2y ago

Edit: below isn’t true. You could set immutable in cache header and the browser wouldn’t verify. —— Original comment: With browser cache, the browser stills need to send a HEAD request to see if the content was modified. These requests are noticeable when networks are spotty (train, weak mobile signals…) Service Worker could cache the request and skip the head requests all together

01HNNWZ0MV43FF 2y ago
Not if you tell the browser it's guaranteed fresh for 10 minutes and then use cache-busting in the URL
- thangngoc89 2y ago
  Oh yeah. The immutable tag right? Total forgot about that
cuu508 2y ago
Set max-age in the Cache-Control header to a high value and the browser will not need to revalidate. When deploying a new version, "invalidate" the browser cache by using a different filename.
- austin-cheney 2y ago
  Or keep the file name and send the file with a query string of some changed numeric value

palsecam 2y ago

Especially since the `stale-while-revalidate` and `immutable` Cache-Control directives are well supported nowadays. Stale-while-revalidate: see https://web.dev/articles/stale-while-revalidate https://web.dev/articles/stale-while-revalidate & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#stale-while-revalidate https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... Immutable: https://datatracker.ietf.org/doc/html/rfc8246 https://datatracker.ietf.org/doc/html/rfc8246 & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#immutable https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... And if using a CDN, `s-maxage` (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#s-maxage https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...) is quite useful. Set it to a long time, and purge the CDN cache on deploy.

exceptione 2y ago
Immutable is what you need. Crazy enough, Chrome has not implemented it. Bug open since 2016: https://issues.chromium.org/issues/41253661 https://issues.chromium.org/issues/41253661 ------------------ EDIT: appears that Chrome suddenly had decided in 2017 to not validate at all on reload anymore, after Facebook had complained to Chrome devs about Chrome being more a drag on their servers compared to other browsers.
- palsecam 2y ago
  To be fair, it’s because Chrome handling of a soft reload is different from Firefox or Safari, and does not lead to revalidating (let alone refetching) assets files. See https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html https://blog.chromium.org/2017/01/reload-reloaded-faster-and... Quoting https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/ https://engineering.fb.com/2017/01/26/web/this-browser-tweak...: > We began to discuss changing the behavior of the reload button with the Chrome team. […] we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones. > Firefox was quick in implementing the cache-control: immutable change and rolled it out just around when Chrome was fully launching their final fixes to reload. > Chrome and Firefox’s measures have effectively eliminated revalidation requests to us from modern version of those browsers.

henriquegogo 2y ago

I was just wondering the same. Browser cache is is old and effective, but unfortunately nobody cares nowadays.

leptons 2y ago
People care when the browser cache is holding on to something - "try clearing your cache" is still a very common tech support solution.

Onavo 2y ago

Because cache invalidation is one of the two hardest problems in computer science.

youngtaff 2y ago

On a session basis browser caches are effective but on a session to session basis it’s likely the content will get evicted as resources from other sites gets cached - there’s an oldish Facebook study where they placed an image in the cache and after 12hrs it had been evicted for 50% of visitors Service Workers offer more controls over cache lifetime, and in Chromium (at least) JS gets stored in an intermediate form (which reduces the re-compile overhead on reuse)

VoodooJuJu 2y ago

Well that would just make it too simple and not blog-worthy.