Take the 2-minute tour ×

I'm looking for the pros/cons of pulling jQuery & other JS libraries from Google API's cloud as opposed to downloading files and deploying directly.

What say you?

My decision

The likelihood of the lib already cached on the users system is the overriding factor for me, so I'm going with a permalink to googleapis.com (e.g. ajax.googleapis.com/ajax/libs/…). I agree with others here that loss of access to the Google server cloud is a minimal concern.

share|improve this question
add comment

9 Answers

up vote 31 down vote accepted

Pros: It may already be cached on the user's system. Google has big pipes. You don't pay for the bandwidth.

Cons: You now have two different ways for your site to become unavailable: A service interruption on your server or one on Google's server.

share|improve this answer
Google has a lot of redundancy and who knows how many data centers so while the risk of an outage on Google's end exists, it is so small as to be almost negligible. –  Kevin Loney Jun 1 '09 at 19:47
Google has had at least two large outages lately. news.google.com/… –  Nosredna Jun 1 '09 at 19:52
Another advantage is having some of your content served by a different domain, so users spend less time waiting on the "two connections per domain" rule built in to most browsers. –  Ben Blank Jun 1 '09 at 19:59
@Ben: this is a vanishingly small consideration on any reasonably configured browser cache. Also applies to the 'risk of outage' which is more properly expressed of a 'risk of outage coinciding with a user's cache expiry. –  Jherico Jun 1 '09 at 20:02
@Nosredna: max-age on the HTTP response is 31536000 seconds or 1 year. –  Kevin Loney Jun 1 '09 at 20:31
show 3 more comments


  • Users in countries embargoed by the U.S. (e.g. Iran) won't get a response from Google
share|improve this answer
I didn't know about this one. Seems you are correct. google.com/search?q=google+iran+javascript+library+jquery –  Nosredna Jun 1 '09 at 20:46
add comment

I've been looking at the real-world performance of the Google loader for jQuery, particularly, and here's what I've found:

  1. Google's servers are quick and plenty reliable.
  2. They are serving from a CDN, which means if you have a lot of overseas users they'll get much better load times.
  3. They are not serving gzipped files. So they're serving a lot more bytes than they need to.

If you know what you're doing in Apache, Lighttpd, or whatever you're serving files with, you could set your cache headers just like Google's and significantly reduce the amount of data your end user has to download by serving it from your own server. You could also combine your scripts at that point and reduce your overall HTTP requests.

Bottom line: Google's performance is good but not great. If you have many many overseas users then Google is probably better, if your users are mostly US-based and maximum performance is your concern, learn about caching, Etags, gzipping, etc. and serve it yourself.

share|improve this answer
According to this page, whether or not they are uncompressed depends on whether you ad {uncompressed:true} to the load call. Is that incorrect? code.google.com/apis/ajaxlibs/documentation/index.html#jquery –  Nosredna Jun 1 '09 at 20:02
That will serve a non-minified version of the JS file. It still doesn't do gzip compression, which can take off another 30-60% of the filesize. –  Gabriel Hurley Jun 1 '09 at 20:30
They are now gzipping the files, so the third item in your list is obsolete. –  Kimmo Puputti Dec 8 '09 at 22:55
add comment


  • Google's connectivity is probably way better than yours
  • It's a free CDN (content distribution network)
  • Your webapp might load faster, since you're using a CDN


  • If/when you need to optimize by repackaging a subset of that third-party JS library, you're on your own, and your webapp might then load slower
share|improve this answer
add comment

In addition to points made by others I'll point out two additional cons:

  • An additional external HTTP request, so assuming you have a Javascript file of your own (almost certain) that's two minimum instead of one minimum; and
  • IMHO because jQuery load is async your entire page can load before the library has loaded so the effects that you do on document ready are sometimes visibly noticeable to the user when they are applied. I think this is not a great user experience.
share|improve this answer
Why the negative vote? Both of these are true. –  cletus Jun 2 '09 at 3:32
Unless you're on some intranet, why is an "external" request bad? It just makes parallel loading easier. (Most browsers limit the number of connections to the same server, not to different servers.) –  Arjan Nov 20 '10 at 11:07
add comment

The pros are quite obvious and are in the other answers :

  • you save bandwidth
  • google is probably more reliable than your server
  • probably cached in most browsers (anyone stats on this ?)

But the cons can be very tricky :

  • If you are using https, you will get an error on most browsers as your certificate isn't valid for google's domain, only yours. This is a major issue for https.
share|improve this answer
add comment

I think what would be cool to do is run A/B tests and see what the latency is to load minified version of jquery from Google's servers vs your server. Hopefully that'll put things into perspective. Chances are the Google server might be faster, but in terms of accepting responsibility of down time, nothing beats hosting it yourself.

share|improve this answer
But don't forget that jQuery is so popular that the user has probably been somewhere else that used Google's copy, so it's cached on the user's computer for a huge gain and one less http request. –  Nosredna Jun 1 '09 at 19:58
add comment


Google's Ajaxlibs offer a very fine-grained "version control" for the included libraries. You can enforce a certain version (e.g. JQuery 1.3.2) or automatically request the latest version from a certain branch (e.g. JQuery 1.3 series -> would currently deliver 1.3.2, but maybe soon 1.3.3).

The later has definitely has benefits: you'll profit from smaller bugfixes/performance improvements without breaking your scripts/plugins.

Maintaining such a multi-library repository on your own can become quite ressource intensive.

share|improve this answer
add comment


  • When afraid of DNS poisoning, or when afraid that some public wireless network might not be trusted, then the non-SSL versions might actually not be served by Google at all, opening up drive-by installation of malware. (But: caching is set to be a full year, so even though many browsers will issue a If-Modified-Since request for cached content when hitting refresh, this might still be a theoretical issue as most users will already have cached the resources while using another network.)

  • When taking extreme care for your visitors' privacy, you might not want Google to record visits to your site by using their CDN. (Quite theoretical as well, as the same note on caching applies.)

share|improve this answer
add comment

Your Answer


