5 ms·

Aren't they also useful because if you and I use the same CDN for our libraries, we both use the same library/version, and a user visits my site and then visits

by jmkni 12y ago

Aren't they also useful because if you and I use the same CDN for our libraries, we both use the same library/version, and a user visits my site and then visits your site, the libraries are already cached in the browser? If we both store those libraries locally, the library is loaded twice. That's my understanding of it anyway.

TheLoneWolfling 12y ago
This is where links that have a hash would be useful. (I.e. "This links points to this file - if you already have the file with this hash use it instead")
eli 12y ago
Yes, though there's some debate as to how often this actually matters. A surprisingly large number of the general web public comes in with a completely cold cache.
nahname 12y ago
That would only occur if the sites referenced exactly the same version of the same library on the same CDN with the same URL.
michaelmior 12y ago
Very often people concatenate and minify different assets, which is another reason that this sharing doesn't occur much in practice.
- riskable 12y ago
  ...which creates another problem with optimization: As soon as you make a change--no matter how small--to a single one of those concatenated assets you now have to deliver the entire new combined asset to the client. If you make changes to your JS/CSS assets on a regular basis (rapid iteration anyone?) this means your clients might be best served via individual assets (depending on your traffic patterns). I have solved this problem myself by avoiding concatenation and using the browser's IndexedDB to store assets that can be loaded dynamically (JS, CSS, and client-side templates). Assets like this get downloaded over a WebSocket connection which provides the same advantage of SPDY in that no re-negotiation is necessary. You can see the implementation of this here: https://github.com/liftoff/GateOne/blob/master/gateone/core/server.py#L2736 https://github.com/liftoff/GateOne/blob/master/gateone/core/... ...and the client side code is here: https://github.com/liftoff/GateOne/blob/master/gateone/static/gateone.js#L1450 https://github.com/liftoff/GateOne/blob/master/gateone/stati... (Including the functions immediately following that one)

by jmkni 12y ago

TheLoneWolfling 12y ago

This is where links that have a hash would be useful. (I.e. "This links points to this file - if you already have the file with this hash use it instead")

eli 12y ago

Yes, though there's some debate as to how often this actually matters. A surprisingly large number of the general web public comes in with a completely cold cache.

nahname 12y ago

That would only occur if the sites referenced exactly the same version of the same library on the same CDN with the same URL.

michaelmior 12y ago

Very often people concatenate and minify different assets, which is another reason that this sharing doesn't occur much in practice.

riskable 12y ago
...which creates another problem with optimization: As soon as you make a change--no matter how small--to a single one of those concatenated assets you now have to deliver the entire new combined asset to the client. If you make changes to your JS/CSS assets on a regular basis (rapid iteration anyone?) this means your clients might be best served via individual assets (depending on your traffic patterns). I have solved this problem myself by avoiding concatenation and using the browser's IndexedDB to store assets that can be loaded dynamically (JS, CSS, and client-side templates). Assets like this get downloaded over a WebSocket connection which provides the same advantage of SPDY in that no re-negotiation is necessary. You can see the implementation of this here: https://github.com/liftoff/GateOne/blob/master/gateone/core/server.py#L2736 https://github.com/liftoff/GateOne/blob/master/gateone/core/... ...and the client side code is here: https://github.com/liftoff/GateOne/blob/master/gateone/static/gateone.js#L1450 https://github.com/liftoff/GateOne/blob/master/gateone/stati... (Including the functions immediately following that one)