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

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

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

[01HNNWZ0MV43FF]

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

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