5 ms·

The point about the CDN cache is not true. It is commonly claimed, but often times it is not the case that jQuery is often cached if you use a CDN. It is "som

The point about the CDN cache is not true. It is commonly claimed, but often times it is not the case that jQuery is often cached if you use a CDN. It is "sometimes" cached, and best performance for most websites is probably to concatenate and minify jQuery in with the site's JS files.

lrem 13y ago
I can see why your statement can be true, but do you have any actual data on this? Or are we both just guessing? ;) (No, I don't have data on mine, I don't even work in this field.)
- LocalPCGuy 13y ago
  Discussion of the issue here (disclaimer, I started the pull request) - https://github.com/h5bp/html5-boilerplate/pull/1327 https://github.com/h5bp/html5-boilerplate/pull/1327 The basic gist is that there is great fragmentation in the cache eco-system, and so there is no guarantee that the user actually has the version of jQuery cached that you are requesting. Alex Sexton brought up in a talk at jQueryTO that there are also the time for the DNS request itself to consider in any discussion of speed, if you concatenate/minify your code it will eliminate a DNS request. Resources discussed in that page: http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... http://www.stevesouders.com/blog/2011/08/17/http-archive-nine-months/ http://www.stevesouders.com/blog/2011/08/17/http-archive-nin... http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... The end conclusion was that for H5BP it didn't make sense to remove the CDN reference, but for your own site it might - you should test it and see. It also depends on your audience (will the CDN move the files closer geographically?). In the end, ~40k (gzipped) is not going to make or break your website's performance.
  - glitchdout 13y ago
    I disagree with your assessment (and so does the majority of people on that pull request, it seems). It's always better to use a CDN because: 1. It has a chance to be already cached (specially if you use Google's CDN). 2. All browsers nowadays do 6 parallel requests per host. So using DNS prefetching with `rel=dns-prefetch` will be faster. 3. If you bundle jQuery with your site's JS files, every time you change a single JS file of your own, your users will be forced to re-download your bundled jQuery. Seems pretty inefficient to me.
    - youngtaff 13y ago
      If you're using HTTPS then "it's always better to use a CDN" is unlikely to be true due to the costs of negotiating the secure connection. 1. Is open to debate and we have no real numbers of this - hopefully the resource timing API will all us to shed some light on the issue 2. Not sure how the number of connections is relevant as the connection to the CDN will be a new one. 3. Agree with this, people need to merge files that naturally fit together an have similar patterns of change
    - LocalPCGuy 13y ago
      It wasn't MY assessment, I just posted the assessment of other s to start the conversation. I don't think you should never use a CDN, there are quite valid reasons to do so. But people shouldn't go around saying that is the only way to go either. It should depend on your site, and the testing you do on that site.
- etler 13y ago
  I have some data: http://w3techs.com/blog/entry/jquery_now_runs_on_every_second_website http://w3techs.com/blog/entry/jquery_now_runs_on_every_secon... Of the top 10k sites 58.8% use jQuery. That's good! But only 26.6% use a cdn. Leaving only 15.6%. That's bad... But 94.2% use Google's. Which is still 14.7%! That's good! http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... But only 1% use the newest version of jQuery. Leaving only 0.15%. That's bad... http://www.quora.com/User-Behavior/How-many-websites-does-an-average-user-visit-per-day http://www.quora.com/User-Behavior/How-many-websites-does-an... But users visit on average 89 sites per month. Which gives us 12.5%. That's good! http://stevesouders.com/cache.php http://stevesouders.com/cache.php But default browser cache sizes are small. That's bad... http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/ http://www.webperformancetoday.com/2013/06/05/web-page-growt... But the average website is about 1MB so with a 50MB cache about 50 sites can be cached. Which leaves about 7.2%. That's... OK? OK. So I don't actually know if a cdn cache hit is all that likely, but the situation is a bit worse, and a bit better than most people think. Of course, using a cdn is still better than hosting yourself. If you bundle your jQuery then every time your site updates it needs to be redownloaded. If you serve it seperately on your domain, you won't have the distribution benefit of a cdn. Should you use Google's cdn instead of a different commercial cdn provider that's faster? In that case I'm not sure.

lrem 13y ago

I can see why your statement can be true, but do you have any actual data on this? Or are we both just guessing? ;) (No, I don't have data on mine, I don't even work in this field.)

LocalPCGuy 13y ago
Discussion of the issue here (disclaimer, I started the pull request) - https://github.com/h5bp/html5-boilerplate/pull/1327 https://github.com/h5bp/html5-boilerplate/pull/1327 The basic gist is that there is great fragmentation in the cache eco-system, and so there is no guarantee that the user actually has the version of jQuery cached that you are requesting. Alex Sexton brought up in a talk at jQueryTO that there are also the time for the DNS request itself to consider in any discussion of speed, if you concatenate/minify your code it will eliminate a DNS request. Resources discussed in that page: http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... http://www.stevesouders.com/blog/2011/08/17/http-archive-nine-months/ http://www.stevesouders.com/blog/2011/08/17/http-archive-nin... http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... The end conclusion was that for H5BP it didn't make sense to remove the CDN reference, but for your own site it might - you should test it and see. It also depends on your audience (will the CDN move the files closer geographically?). In the end, ~40k (gzipped) is not going to make or break your website's performance.
- glitchdout 13y ago
  I disagree with your assessment (and so does the majority of people on that pull request, it seems). It's always better to use a CDN because: 1. It has a chance to be already cached (specially if you use Google's CDN). 2. All browsers nowadays do 6 parallel requests per host. So using DNS prefetching with `rel=dns-prefetch` will be faster. 3. If you bundle jQuery with your site's JS files, every time you change a single JS file of your own, your users will be forced to re-download your bundled jQuery. Seems pretty inefficient to me.
  - youngtaff 13y ago
    If you're using HTTPS then "it's always better to use a CDN" is unlikely to be true due to the costs of negotiating the secure connection. 1. Is open to debate and we have no real numbers of this - hopefully the resource timing API will all us to shed some light on the issue 2. Not sure how the number of connections is relevant as the connection to the CDN will be a new one. 3. Agree with this, people need to merge files that naturally fit together an have similar patterns of change
  - LocalPCGuy 13y ago
    It wasn't MY assessment, I just posted the assessment of other s to start the conversation. I don't think you should never use a CDN, there are quite valid reasons to do so. But people shouldn't go around saying that is the only way to go either. It should depend on your site, and the testing you do on that site.
etler 13y ago
I have some data: http://w3techs.com/blog/entry/jquery_now_runs_on_every_second_website http://w3techs.com/blog/entry/jquery_now_runs_on_every_secon... Of the top 10k sites 58.8% use jQuery. That's good! But only 26.6% use a cdn. Leaving only 15.6%. That's bad... But 94.2% use Google's. Which is still 14.7%! That's good! http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... But only 1% use the newest version of jQuery. Leaving only 0.15%. That's bad... http://www.quora.com/User-Behavior/How-many-websites-does-an-average-user-visit-per-day http://www.quora.com/User-Behavior/How-many-websites-does-an... But users visit on average 89 sites per month. Which gives us 12.5%. That's good! http://stevesouders.com/cache.php http://stevesouders.com/cache.php But default browser cache sizes are small. That's bad... http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/ http://www.webperformancetoday.com/2013/06/05/web-page-growt... But the average website is about 1MB so with a 50MB cache about 50 sites can be cached. Which leaves about 7.2%. That's... OK? OK. So I don't actually know if a cdn cache hit is all that likely, but the situation is a bit worse, and a bit better than most people think. Of course, using a cdn is still better than hosting yourself. If you bundle your jQuery then every time your site updates it needs to be redownloaded. If you serve it seperately on your domain, you won't have the distribution benefit of a cdn. Should you use Google's cdn instead of a different commercial cdn provider that's faster? In that case I'm not sure.