Should I link to Google API's cloud for JS libraries?

Question

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.

Answer 1

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.

Answer 2

Pros:

• 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

Cons:

• 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

Answer 3

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.

Answer 4

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.

Answer 5

Con

• Users in countries embargoed by the U.S. (e.g. Iran) won't get a response from Google

Answer 6

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.

Answer 7

Pro:

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.

Answer 8

Posted in wrong place :(

Answer 9

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.