[mh-cx]

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.

[palsecam]

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://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

Immutable: https://datatracker.ietf.org/doc/html/rfc8246 & 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/Ca...) is quite useful. Set it to a long time, and purge the CDN cache on deploy.

[exceptione]

  Immutable

is what you need. Crazy enough, Chrome has not implemented it. Bug open since 2016: 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]

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...

Quoting 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.

[exceptione]

I just wrote my edit before I saw yours. Must have been a cache problem :)

[palsecam]

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton (cf. https://www.Karlton.org/2017/12/naming-things-hard/ or https://MartinFowler.com/bliki/TwoHardThings.html)

;-)

[traverseda]

And off by one errors

[jdsleppy]

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.

[exceptione]

+ 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.

[wmfiv]

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

[youngtaff]

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]

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]

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]

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

[mh-cx]

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;
  }

[youngtaff]

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)

[thangngoc89]

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

[cuu508]

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]

Or keep the file name and send the file with a query string of some changed numeric value

[01HNNWZ0MV43FF]

Not if you tell the browser it's guaranteed fresh for 10 minutes and then use cache-busting in the URL

[thangngoc89]

Oh yeah. The immutable tag right? Total forgot about that

[VoodooJuJu]

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

[Onavo]

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

[henriquegogo]

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

[leptons]

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