Comments on: 3 reasons why you should let Google host jQuery for you

By: Dave Ward

Dave Ward — Sat, 28 Jan 2012 03:23:35 +0000

You shouldn’t do that in production. In order to reliably serve up the latest version for /1 or /1.n, the CDN responds with very short caching expiration headers. So, you lose almost all of the caching benefit. At that point, serving jQuery from your own site with proper caching headers would actually be faster for returning visitors.

By: Paolo Brocco

Paolo Brocco — Thu, 26 Jan 2012 15:10:24 +0000

Hi, I don’t know if somebody mentioned it, but ideally all website would link to jquery (hosted on google ajax libraries) without specifying an exact version. Because if a website links to jquery 1.6.0, the other to 1.6.1, the other to 1.6.4 then it will be the same as linking to your server one.

So e.g. instead of linking to ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
we should all link to ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js… see the difference? Asap jquery is updated everybody is pointing already to the last version and the caching is there and no need to update your website.

Disadvantage: if jquery breaks something you have to correct your scripts or link to an older version. But I would risk that, after all if something stops working then you just link to the older version and voila: fixed.

By: Dave Ward

Dave Ward — Tue, 24 Jan 2012 19:45:54 +0000

A CDN doesn’t need to enable CORS for you to use its assets on your page. That’s only necessary for AJAX requests, not for referencing third party scripts.

By: John AtWork

John AtWork — Tue, 24 Jan 2012 14:25:39 +0000

I can’t use google as my CDN because they have not enabled CORS.

By: MegaSteve4

MegaSteve4 — Thu, 19 Jan 2012 20:57:40 +0000

Ah ok… Worth noting that that link does fail if you try and run it from a local HTML file say on your desktop….as I did I guess ‘Live’ would be different – great article though.

By: Chris

Chris — Thu, 12 Jan 2012 23:16:29 +0000

Actually, that’s done on purpose. This way, if you are on an HTTPS page, it matches that.

By: MegaSteve4

MegaSteve4 — Thu, 12 Jan 2012 23:13:46 +0000

DEAD LINK ALERT – I would guess that WordPress is stripping the h t t p from the beginning of the link resulting in this “//ajax.googleapis.com…………….”

This is happening in the link at the top of the tut and bottom

But great tut v informative

By: HyperPac´s site » Blog Archive » Wordpress Visual Editor broken after Update 3.3.1 (again)

Tue, 10 Jan 2012 12:33:44 +0000

[...] And this explains why you may wanna use it, even if your visual editor works fine: http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/ [...]

By: Chris

Chris — Wed, 04 Jan 2012 20:03:45 +0000

I wonder if Microsoft’s jQuery hosting domain got tagged as phishing as well

By: Dave Ward

Dave Ward — Wed, 04 Jan 2012 19:57:21 +0000

Using a local fallback (e.g. http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cdn-hosted-jquery-with-a-local-fall-back-copy.aspx) will handle DNS issues like that automatically, without penalizing the majority of users who have good DNS.

edit: Looks like this is already fixed: http://forums.opendns.com/comments.php?DiscussionID=12755#Item_12

By: jamie

jamie — Wed, 04 Jan 2012 19:54:27 +0000

it is a headache indeed – I’ve just switched back to local :)

By: Al

Al — Wed, 04 Jan 2012 11:19:59 +0000

One major problem we have hit today… OpenDNS has just categorised apis.google.com as a Phising site, meaning anyone who uses OpenDNS can’t access the jQuery we link to via Goggle CDN

Ok, not a Google problem, but a big enough headache today!!

By: Dave Ward

Dave Ward — Thu, 29 Dec 2011 20:26:52 +0000

Nothing wrong with a little caution. It’s probably a safe assumption that Google’s tracking you whenever they can. This is just one of those few situations where even Google shouldn’t be able to extract any useful tracking information from the data they’ll be getting.

By: Chris

Chris — Thu, 29 Dec 2011 20:23:15 +0000

Oh, you are right about the caching! Guess I was being overly cautious

By: Dave Ward

Dave Ward — Thu, 29 Dec 2011 20:18:56 +0000

The primary advantage of using a far-future expires/cache-control header is that the browser doesn’t need to make any request at all to use its locally cached assets, not even a 304 check.

You’ll see a 304 when you force a refresh in some browsers, but no request at all when you’re making regular requests to pages. Click around my site here (not manually refresh) and watch the network tab in your browser. You won’t see an HTTP request for the Google CDN reference after it’s been cached once (at least not for a year).