3 ms·

And this page took 9.7 seconds to open from Perth, Australia on a 10mbit connection. CDNs are useful because they load content closest to where the user is loc

by thejosh 12y ago

And this page took 9.7 seconds to open from Perth, Australia on a 10mbit connection. CDNs are useful because they load content closest to where the user is located.

dozzie 12y ago
I think this would be more related to your 10 millibit connection.
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 thejosh 12y ago

And this page took 9.7 seconds to open from Perth, Australia on a 10mbit connection. CDNs are useful because they load content closest to where the user is located.

dozzie 12y ago

I think this would be more related to your 10 millibit connection.

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)