4 ms·

Then you should do what Facebook does (https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook https://code.facebook

by rakoo 10y ago

Then you should do what Facebook does (https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook https://code.facebook.com/posts/557147474482256/this-browser...): content-addressed resources. Have a resource be available not at /resources/something.js, but at /resources/<sha1(something.js)>; whenever there is a new version of something.js, the sha1 changes and is put in your root document, and the browser will never again try to reach the older version, which you know is invalid now.

jdminhbg 10y ago
This is also the default in Rails with the asset pipeline since 4.0.
- byroot 10y ago
  It's even older than that. Sprockets always have been content addressed, but in early versions it used to leave non digested aliases (by mistake actually), and some people relied on it. But ever since 3.1 (Aug 2011) Rails defaulted to content addressed assets.
perfmode 10y ago
Content addressing of data is one of my favorite ideas in the field.
jjoe 10y ago
But what happens when you need to cache the actual page not just static resources? That's what the content-addressed resources trick doesn't address.
- cortesoft 10y ago
  You cache the actual page with a much shorter cache timeout.
- metafunctor 10y ago
  Then just cache the actual page. The cached version refers to some possibly old versions of the static resources, so your server needs to be able to serve old versions for a period of time.
btilly 10y ago
And what if the resource in question is a dynamically generated minified thing? Do I have to dynamically generate it within the main html page to be able to figure out the sha? These are big complex workarounds for a problem that is easily solved at another layer.
- acdha 10y ago
  Typically these are shared resources and can be generated once and saved so your HTML page would simply be checking file metadata generated at the time the app was built. If it was truly custom, you could either do cached on-demand generation or find some other portion of the cache key which reliably changes on updates – e.g. I've seen people use things like Git commit ID + feature flags.

by rakoo 10y ago

jdminhbg 10y ago

This is also the default in Rails with the asset pipeline since 4.0.

byroot 10y ago
It's even older than that. Sprockets always have been content addressed, but in early versions it used to leave non digested aliases (by mistake actually), and some people relied on it. But ever since 3.1 (Aug 2011) Rails defaulted to content addressed assets.

perfmode 10y ago

Content addressing of data is one of my favorite ideas in the field.

jjoe 10y ago

But what happens when you need to cache the actual page not just static resources? That's what the content-addressed resources trick doesn't address.

cortesoft 10y ago
You cache the actual page with a much shorter cache timeout.
metafunctor 10y ago
Then just cache the actual page. The cached version refers to some possibly old versions of the static resources, so your server needs to be able to serve old versions for a period of time.

btilly 10y ago

And what if the resource in question is a dynamically generated minified thing? Do I have to dynamically generate it within the main html page to be able to figure out the sha? These are big complex workarounds for a problem that is easily solved at another layer.

acdha 10y ago
Typically these are shared resources and can be generated once and saved so your HTML page would simply be checking file metadata generated at the time the app was built. If it was truly custom, you could either do cached on-demand generation or find some other portion of the cache key which reliably changes on updates – e.g. I've seen people use things like Git commit ID + feature flags.