←back to thread

260 points gherkinnn | 5 comments | | HN request time: 0.201s | 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 #
1. traverseda ◴[] No.42167475[source]
And off by one errors
replies(2): >>42168340 #>>42168349 #
2. ohthatsnotright ◴[] No.42168340[source]
And dates and times And currency
replies(2): >>42169262 #>>42172208 #
3. 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

4. yndoendo ◴[] No.42169262[source]
Manage date and time in UTC/Zulu. Append the time zone if that meta is needed and store both the client and server for backend. That way you don't have to deal with time travel and can handle time shifts.

I would say that concurrency is a caching issue once proper locking has been set.

5. zbentley ◴[] No.42172208[source]
And ce conditions rainduced by concurrency.