Is using a CDN for jQuery (or other static files/scripts) really a good idea?_问答_开发者

It says everywhere to use a CDN, such as Google's or Microsoft's AJAX CDN to load static script libraries, such as jQuery in my case.

I don't understand how this is really helpful to make my site any faster. In firebug, I'm getting around 300ms both for Google and Microsoft AJAX servers when I load jQuery, and in Chrome, I'm getting around 100ms (dunno what creates the difference, no downloads going on, tried both several times, but anyway that's not the point), my site will have an estimated average of 30 to 40ms response time when I deploy. How can loading the files the CDN do any good to my site? It will make everything even worse!

I understand that when I visit many sites using, say, jQuery from Google's CDN, it will have to "download" the script only once for a very long time, but my browser still tries to connect to the Google's server, and ask for the script file, and then receive 304 not modified status code. During this round trip of 200ms (average of Chrome and FF), I wait. But if I hosted the script file myself, then it will (down)load MUCH faster, about five times, which is an important factor for user experience. Maybe 200ms is not a VERY BIG deal, but it's still a difference and I want to know why it's recommended to use a CDN instead of hosting files ourselves. In the end, after one-time load, the browser will cache the script for my site as well and if I use CDN, browser will ask the CDN for the script anyway which will lag my website.

Update: I am from Turkey, and that may be the primary reason to have high roundtrips. Most of my visitors will be from here, so I'm asking would it be beneficial for my site hosted on server开发者_StackOverflows in Turkey, and users of my site who are also at Turkey, to use CDN. Definitely not good for roundtrips, but maybe I'm missing out something.

Two part answer:

You shouldn't be seeing 304s
But is it a good idea?

You Shouldn't Be Seeing 304s

I understand that when I visit many sites using, say, jQuery from Google's CDN, it will have to "download" the script only once for a very long time, but my browser still tries to connect to the Google's server, and ask for the script file, and then receive 304 not modified status code.

It shouldn't, not if it's respecting the Cache-Control header:

Cache-Control:public, max-age=31536000

...which says from the date on the resource, the browser can cache it for up to a year. No need for any HTTP request at all (and that's what I see in Chrome unless I force it, no request at all, just a note saying "from cache"; fired up Firefox and made sure Firebug was on for all pages, came to StackOverflow for the first time in a long time with Firefox [which I only use for testing], and sure enough, it didn't issue any request for jquery at all).

E.g., maybe it takes 200ms for a 304 response, but if your browser is caching correctly, it'll be 0ms for a load-from-cache.

The full set of relevant headers I see on a forced request are:

Cache-Control:public, max-age=31536000
Date:Wed, 17 Aug 2011 21:56:52 GMT
Expires:Thu, 16 Aug 2012 21:56:52 GMT
Last-Modified:Fri, 01 Apr 2011 21:23:55 GMT

...so my browser shouldn't have to request that path again for nearly a year.

See @Dave Ward's comment below: To get max caching results, use the full release number, e.g.:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'></script>
<!--                               very specific ---^^^^^                      -->

rather than

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<!--                               very generic ----^                      -->

Okay, but is it a good idea?

That's entirely up to you. Even with a fallback like this:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<script>
if (typeof jQuery === "undefined") {
    document.write("<scr" + "ipt src='/my/local/jquery.js'></scr" + "ipt>");
}
</script>

...or similar, the UX if the CDN is down is going to be awful. The browser is going to spin for ages trying to connect to it. That kind of fallback will only help if the CDN quickly replies with a failure, which is unlikely.

This means if Google's CDN goes down, you would have to quickly adjust what you're serving to use your local copy instead. So defending against that becomes a monitoring exercise (of Google's servers; don't overdo it or they'll be displeased) with a failover at the server level to start serving pages with a local path. (Or a Microsoft path, on the theory that Google and Microsoft probably aren't sharing underlying CDN technology, given how well they get along.)

For me, the answer for most sites is probably: Go ahead and use the CDN, react if and when Google's CDN for libraries goes down. The flip side is: If you're happy with your overall page load performance loading it from your server, little harm in doing that until or unless traffic is high enough that you're looking to eke every last bit of performance out of things. But lots (and lots and lots) of sites rely on Google's CDN, if it goes down, your site will be far from alone in failing...

Could give you 6,953 reasons why I still let Google host jQuery for me.

The main advantages being

Decreased Latency
Increased parallelism
Better caching

one important note on why Firefox doesn't cache what it should cache ! FIREBUG has an small feature called "Disable Browser Cache" developers and designers most of the times turn it on and so firefox don't cache anything even when firebug is not active !! so just open 'firebug' > go to 'Net' tab >

Is using a CDN for jQuery (or other static files/scripts) really a good idea?

i think this is very costly bug in firebug which cause a lot of bandwidth wasting for poor developers !

The point is, that if many websites reference the CDN-based versions, chances are high that users coming to your site already have the script in their cache.