3 ms·

Just to clarify. General CDNs tend to be a good idea of you are having latency issues. Standard libraries for major JavaScript project, all served from a singl

Just to clarify. General CDNs tend to be a good idea of you are having latency issues. Standard libraries for major JavaScript project, all served from a single shared CDN (like Google, maxcdn, cdnjs, etc) also tend to be called "CDNs" but this is a little confusing. Yes, these shared files are often stored on a CDN, but that's not the so-called major benefit of these shared hosts. The main benefit is supposed to be that, if everyone references the same copy of jQuery on one of these shared hosts, the when visitors hit other sites, jQuery will already be in their browser cache. This rarely works in practice. The URLs to these shared libraries. Multiple shared services. Multiple version numbers. HTTPS vs HTTP. The net result is that the probability that someone visiting your site has a copy of the exactly same resource referenced via the exact same URL is very low. With the overhead of having to do a DNS lookup, a TCP connection, TCP slow start, its rarely worth it. Just concat/minify into your own block of JS served from your own systems. Shared JS hosts/CDNs are a terrible and annoying hack, all in an attempt to save 50KB or so

vdaniuk 11y ago
Ugh, I will never understand this reasoning. Overheads of fetching library from a CDN are applicable to the first request. Why do you consider this to be an important factor? Also can you provide any stats/citation that cache hit probability on first request is in fact very low?
- billyhoffman 11y ago
  First, research on hit factor: https://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns https://zoompf.com/blog/2010/01/should-you-use-javascript-li... http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... https://github.com/h5bp/html5-boilerplate/pull/1327#issuecomment-14799362 https://github.com/h5bp/html5-boilerplate/pull/1327#issuecom... I have more recent data on this that is not yet published from my day-to-day work at a web performance company. The pictures has improved somewhat, but not significantly. You are correct, "Overheads of fetching library from a CDN are applicable to the first request" The problem is, because of the fragmentation, every website is asking you to hit a different URL, so every request is a "first request". You aren't leveraging the browser cache. Most sites are already serving you site-specific JS anyway over a warm connection (even more so with HTTP/2), so there is even less benefit to going to a 3rd party host to potentially avoid downloading a few dozen kilobytes. Couple that with the security implications of injecting 3rd party code into your page, its just plain silly and wasteful to do this for a modern website.
  - vdaniuk 11y ago
    jQuery CDN cache hit rate is 99.8%[0], Google CDN numbers should be comparable. So yes, you are leveraging browser cache for most popular libraries. Also I was talking from the subsequent requests from the same client. [0]https://www.maxcdn.com/blog/maxscale-jquery/ https://www.maxcdn.com/blog/maxscale-jquery/
    - billyhoffman 11y ago
      You are confusing browser cache hits with a CDN/edge server cache hit.jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. This sentence should be a big clue: "We usually average around 15,000 hits per second to our CDN with 99.8% of those being cache hits." "We" in that sentence is Kris Borchers speaking collectively about the jQuery foundation, talking a MaxCDN interviewer. But he is not talking about the browser cache. He can't be, because jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. Example: If I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to the same maxcdn.com/jquery.js file, my browser doesn't send any requests! That is the entire point of far-future caching! I was able to use the version of jquery that was in my browser cache. However MaxCDN, or jQuery for that matter, have no idea this hit took place. By the same token, if I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to a different URL like maxcdn.com/master/jquery.js, my browser has a cache miss. /master/jquery.js is not in my browser's cache, I've never been there. MaxCDN, or jQuery for that matter, have no idea that I requested something different then before. CDN cache hit rate has nothing to do with browser caches. In fact, people that are not you, being able to detect if something is in your browser cache or not, is a massive security problem. See my talk at BlackHat in 2007, Many of Jeremiah Grossman's talks at BlackHat (2006, 2007, 2009), or go all the way back to Ed Felton's work on using the timing side channels against browser caches. In the industry, "99.8%" cache hit on a CDN's edge server means that 99.8% of the time the edge server can handle the request, instead of the request having to go all the way to the origin. They have no way of knowing how often a random person on the internet loads a random file from their browser cache. This whole thing proves my point: Calling shared, common, publicly hosted copies of popular JS libraries "CDN's" or "JavaScript CDNs" is just confuses people. CDNs are about reducing latency. Share JS libraries are about trying to avoid requests altogether by leveraging the browser cache, and they are largely ineffective.

vdaniuk 11y ago

Ugh, I will never understand this reasoning. Overheads of fetching library from a CDN are applicable to the first request. Why do you consider this to be an important factor? Also can you provide any stats/citation that cache hit probability on first request is in fact very low?

billyhoffman 11y ago
First, research on hit factor: https://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns https://zoompf.com/blog/2010/01/should-you-use-javascript-li... http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... https://github.com/h5bp/html5-boilerplate/pull/1327#issuecomment-14799362 https://github.com/h5bp/html5-boilerplate/pull/1327#issuecom... I have more recent data on this that is not yet published from my day-to-day work at a web performance company. The pictures has improved somewhat, but not significantly. You are correct, "Overheads of fetching library from a CDN are applicable to the first request" The problem is, because of the fragmentation, every website is asking you to hit a different URL, so every request is a "first request". You aren't leveraging the browser cache. Most sites are already serving you site-specific JS anyway over a warm connection (even more so with HTTP/2), so there is even less benefit to going to a 3rd party host to potentially avoid downloading a few dozen kilobytes. Couple that with the security implications of injecting 3rd party code into your page, its just plain silly and wasteful to do this for a modern website.
- vdaniuk 11y ago
  jQuery CDN cache hit rate is 99.8%[0], Google CDN numbers should be comparable. So yes, you are leveraging browser cache for most popular libraries. Also I was talking from the subsequent requests from the same client. [0]https://www.maxcdn.com/blog/maxscale-jquery/ https://www.maxcdn.com/blog/maxscale-jquery/
  - billyhoffman 11y ago
    You are confusing browser cache hits with a CDN/edge server cache hit.jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. This sentence should be a big clue: "We usually average around 15,000 hits per second to our CDN with 99.8% of those being cache hits." "We" in that sentence is Kris Borchers speaking collectively about the jQuery foundation, talking a MaxCDN interviewer. But he is not talking about the browser cache. He can't be, because jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. Example: If I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to the same maxcdn.com/jquery.js file, my browser doesn't send any requests! That is the entire point of far-future caching! I was able to use the version of jquery that was in my browser cache. However MaxCDN, or jQuery for that matter, have no idea this hit took place. By the same token, if I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to a different URL like maxcdn.com/master/jquery.js, my browser has a cache miss. /master/jquery.js is not in my browser's cache, I've never been there. MaxCDN, or jQuery for that matter, have no idea that I requested something different then before. CDN cache hit rate has nothing to do with browser caches. In fact, people that are not you, being able to detect if something is in your browser cache or not, is a massive security problem. See my talk at BlackHat in 2007, Many of Jeremiah Grossman's talks at BlackHat (2006, 2007, 2009), or go all the way back to Ed Felton's work on using the timing side channels against browser caches. In the industry, "99.8%" cache hit on a CDN's edge server means that 99.8% of the time the edge server can handle the request, instead of the request having to go all the way to the origin. They have no way of knowing how often a random person on the internet loads a random file from their browser cache. This whole thing proves my point: Calling shared, common, publicly hosted copies of popular JS libraries "CDN's" or "JavaScript CDNs" is just confuses people. CDNs are about reducing latency. Share JS libraries are about trying to avoid requests altogether by leveraging the browser cache, and they are largely ineffective.