http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Date: Thu, 13 Jan 2011 16:41:02 GMT
Expires: Fri, 13 Jan 2012 16:41:02 GMT
Cache-Control: public, max-age=31536000

Date: Fri, 14 Jan 2011 16:45:21 GMT
Expires: Fri, 14 Jan 2011 15:45:21 GMT
Cache-Control: public, must-revalidate, proxy-revalidate, max-age=3600

Parallel script loading is nice... unless your website use scripts that are dependent on certain core libraries (ie, jQuery) being loaded first. If you are using Google CDN, you may want to consider using LABjs as it will allow you to asynchronously load several resources from your own domain and external domains without blocking while retaining chaining dependencies. http://LABjs.com/ [NOTE: The LABjs website appears to be down right now and you may need to use a search for more info.]

The biggest Con in my eyes is that it creates another point of failure for your site. If there is a problem with the CDN, it affects your site.

In theory, this should be very rare, but I have had problems serving the Dojo Toolkit from the Google CDN. In fairness, if you don't create a custom build of Dojo you can end up having to download a huge number of files. In my case it seemed like any latency on the CDN caused my site to slow to a crawl. This problem would probably not be that noticeable if you are only including the single jQuery file, but it's worth noting that latency problems can happen on the CDN.

I did not realize that you could leave out the specific versions like you mentioned to get the latest. Interesting tip, thanks for sharing it.

The various Page Speed tools (Yslow etc) will ping a warning to say you're not using long cache expiry dates if you don't opt for the very specific versions.

@David - you can always fall back to a local copy of jQuery if the CDN is down.. have a look at the html5 boilerplate code (http://html5boilerplate.com/) for example..

Head JS (headjs.com) is one quite useful script for helping to load scripts in parallel but execute in order. It helped to reduce amount of load time even when part of the scripts are still loaded from Google's CDN (but just using Head JS as loader). There's also quite bit of other features in it so I surely recommend to look at it.

@John:

I'd highly recommend *always* pointing to the specific version of jQuery you've tested your site against.

There are just too many changes between jQuery point releases that could impact your code in a way that's difficult to track down. There's nothing worse then users reporting your sites not working, yet you know that you haven't made any changes, only to eventually track down the issue as a change to some external files being served up that you can't control. While this could happen if the CDN is down as well, at least then you'll see more obvious JS errors instead of the more subtle changes that can occur if behavior changes.

I've just been using jQuery long enough (since like jQuery 1.1) I've just seen enough changes in point releases that caused me to update code to realize it's a bad thing to automatically point to the latest version of jQuery in a production environment.

The only time I would think about using this technique is for a development version of a jQuery plug-in or for a test environment, where you just want to make sure your code works w/the latest stable version.

@Geoff, that's an interesting technique. I think that would work if the CDN is unavailable but wouldn't help if it is just slow. So it looks like a great idea if you're going to use a CDN, but wouldn't have solved my dojo problem.

CON: when Google went down in the UK it took a massive number of sites off-line. It even took jquery.com down as they were even using Googles CDN.

But, Google going down is extremely rare.

We always use Googles CDN. But we now have something in our config files to switch between cloud and local files. If it happened again, all we need to do is change a flag in the config to switch over (not just jquery, but jqueryui, all the associate CSS files, etc).

As with anything, just make sure you have a backup plan.

Browsers such as Chrome or Firefox should have a precached version of all most famous JS library ! All web sites are using JQuery or Mootools or Prototype, it will be a big big improvement !

Although Google's servers are very fast (and in many cases your user may already have it loaded), we took the approach of generating a single, combined and minimized JS file for our site. We take jQuery, Google Analytics, AddThis and Mr. Switzer's qForms and bundle it into a core.js file that we dynamically name and push to our S3 bucket. A single, minimized and gzipped asset will probably trump multiple connections even if you have a fast link to somewhere like Google.

@Brian G

Are you sure you are serving your single js code gzip'd on S3? gzip speeds up page load times significantly but S3 doesn't have standard support for gzip and trying to force it on all browsers can be problematic.

Instead I would suggest checking out google's new google storage for developer's service, it is feature compatible with S3, but unlike S3 they automatically gzip css/js when possible and even sets correct content-type headers. I've even found load times to be better then S3.

I'd also recommend google's closure compiler service when minifying and combining your source, it has the best compression rate and can even optimize the code for faster performance.

Cheers

About the CON's point 1, I think I'll have bigger things to worry about than some malicious script running on my site if Google's servers get hacked :)