←back to thread

260 points gherkinnn | 1 comments | | HN request time: 0.001s | source
Show context
mh-cx ◴[] No.42164537[source]
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.

replies(7): >>42164573 #>>42164584 #>>42164743 #>>42168597 #>>42169927 #>>42170948 #>>42173755 #
palsecam ◴[] No.42164743[source]
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.

replies(1): >>42166681 #
exceptione ◴[] No.42166681[source]

  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.

replies(1): >>42166914 #
palsecam ◴[] No.42166914[source]
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.

replies(1): >>42166966 #
exceptione ◴[] No.42166966[source]
I just wrote my edit before I saw yours. Must have been a cache problem :)
replies(1): >>42167004 #
palsecam ◴[] No.42167004[source]
“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)

;-)

replies(1): >>42167475 #
traverseda ◴[] No.42167475[source]
And off by one errors
replies(2): >>42168340 #>>42168349 #
1. CBarkleyU ◴[] No.42168349[source]
That's a nice addendum to the quote, actually. Will use it in future.

> There are only two hard things in computer science: Cache invalidation, naming things and off-by-one errors