32

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.

Community
  • 1
  • 1
Chip Kaye
  • 1,397
  • 12
  • 13

9 Answers9

37

Con

  • Users in countries embargoed by the U.S. (e.g. Iran) won't get a response from Google
Community
  • 1
  • 1
bdukes
  • 152,002
  • 23
  • 148
  • 175
  • I didn't know about this one. Seems you are correct. http://www.google.com/search?q=google+iran+javascript+library+jquery – Nosredna Jun 01 '09 at 20:46
  • 1
    Very true; see also [Best way to use Google's hosted jQuery, but fall back to my hosted library on Google fail](http://stackoverflow.com/questions/1014203/best-way-to-use-googles-hosted-jquery-but-fall-back-to-my-hosted-library-on-goo). – Arjan Nov 20 '10 at 11:12
35

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.

Nosredna
  • 83,000
  • 15
  • 95
  • 122
  • 6
    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 01 '09 at 19:47
  • 6
    Google has had at least two large outages lately. http://news.google.com/news?q=google%20outage&um=1&ie=UTF-8&sa=N&hl=en&tab=wn – Nosredna Jun 01 '09 at 19:52
  • 10
    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 01 '09 at 19:59
  • 1
    @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 01 '09 at 20:02
  • @Jherico, good point. The browser won't even check google if the library is already in the cache, will it? So even if google has the odd weird outage, it won't necessarily affect the user. Does anyone know how long the expiration is for these served libs? – Nosredna Jun 01 '09 at 20:05
  • 1
    @Nosredna: max-age on the HTTP response is 31536000 seconds or 1 year. – Kevin Loney Jun 01 '09 at 20:31
  • Amazing how dependent we're willing to be on Google. (I'm no exception -- I depend on GMail for work.) Anyway, regarding the question, I've started embedding the Yahoo CSS Reset into my stylesheets because of a few major delays I experienced getting it from them. I know, they're no Google, but the principle is the same. – harpo Jun 03 '09 at 04:08
  • 1
    if you use the google loader script, you can add a callback function if the load fails. You can then always decide to load your Js library from your server anyway. – Jasper De Bruijn Feb 09 '10 at 14:43
10

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.

Gabriel Hurley
  • 39,690
  • 13
  • 62
  • 88
  • According to this page, whether or not they are uncompressed depends on whether you ad {uncompressed:true} to the load call. Is that incorrect? http://code.google.com/apis/ajaxlibs/documentation/index.html#jquery – Nosredna Jun 01 '09 at 20:02
  • 4
    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 01 '09 at 20:30
  • 2
    They are now gzipping the files, so the third item in your list is obsolete. – Kimmo Puputti Dec 08 '09 at 22:55
2

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.
antesima
  • 23
  • 1
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
Dave W. Smith
  • 24,318
  • 4
  • 40
  • 46
2

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.
cletus
  • 616,129
  • 168
  • 910
  • 942
  • 2
    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
1

Con:

  • 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.)

Arjan
  • 22,808
  • 11
  • 61
  • 71
1

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.

gsvolt
  • 184
  • 8
  • 2
    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 01 '09 at 19:58
1

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.

fbuchinger
  • 4,494
  • 2
  • 30
  • 31