Use Google's Javascript CDN for jQuery

I second this request.

And the version selector idea is pretty neat! ;)

I'm not sure it's possible to take advantage of Google's AJAX API in Drupal 5 without hacking Drupal core. I got a proof of concept working in Drupal 6 though. Unfortunately, Google's AJAX API doesn't include the 1.2.4a version of jQuery that ships with the 6.x-1.0 version of the module. Google's site says "1.2.5 and 1.2.4 are not hosted due to their short and unstable lives in the wild."

The Google AJAX API wouldn't make a good wholesale replacement for the local jquery.js file, since someone might be using Drupal locally without being connected to the Internet. But it would be a nice optional feature. When I get some more time, I'll add an administrative page to my proof of concept, to allow admins the option of switching between the Google's AJAX API and the local jQuery file.

The admin interface could also provide the option to designate a specific version of jquery to be added, but I'm not sure if that's wise since each new version of jQuery has the potential to introduce new issues. Is the version included with a release of jQuery Update a matter of timing or are there specific testing considerations?

Here's a patch for the Drupal 6 version that mostly works, except that it doesn't take into account the jquery_update_get_version function. I believe that will require that the available versions be pre-populated instead. While the AJAX Libraries API allows you to load the latest 1.x version by specifying "1" in the URL, there is then no way for the jquery_update_get_version function to know the correct version number to return.

I'm going to rework the version field on the administration page to use a pre-populated select box instead of a textfield.

Here's a better patch that returns the correct version number via jquery_update_get_version. It required that the version number be specified via a select box when using the Google AJAX Libraries API.

An alternative might be to periodically download the Google AJAX Libraries API version of jQuery just as a client browser would, parse the file just like the local version, then maybe cache the version number. That's a half-baked idea at this point. I'm open to suggestions. It would be nice to have the flexibility to just specify the latest 1.x version of jQuery and let Google take care of keeping up-to-date.

This is interesting. Why is this preferable over having the file locally? It seems like this would incur a performance penalty on every page load unless you got the local caching thing you mentioned working.

The blog post that's referenced in the initial comment basically states that it's to prevent 40 different versions of fooJSLibrary.js being included all over your site. That's fairly irrelevant here; Drupal provides a centralized jquery.js that's used by all of its installed modules and themes.

Being able to load the latest 1.x compatible code sounds good on paper, but how do you propose handling the necessary replacement files for incompatible core JS files (for example, farbtastic.js is not compatible with 1.2.6)?

In terms of why it is preferable to having the file locally, the blog post from the initial comment goes on to mention additional benefits. I think the first three points listed (caching, gzip, and minification) may be moot with Drupal, but the last three seem to be beneficial.:

# The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
# The servers are fast
# By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!

Can you elaborate on why you think it would "incur a performance penalty on every page load" as it stands? Maybe I'm missing something.

As for the compatibility issues, I was afraid that might be a concern (see my question at the end of comment #2).

Can you elaborate on why you think it would "incur a performance penalty on every page load" as it stands? Maybe I'm missing something.

Well, because of this:

+      $head .= '<script src="http://ajax.googleapis.com/ajax/libs/jquery/'. variable_get('jquery_version', GAL_API_VERSION_DEFAULT) .'/jquery.min.js" type="text/javascript"></script>' . PHP_EOL;

The benefits sound all well and good, but if googeapis.com is slow or times out (or the CDN hosting it, whatever), my entire site hangs until that file is pulled in. I see this fairly often on various sites pulling in AdSense ads via direct linking to Google's .js files. Unless AdSense doesn't do this CDN stuff, but it seems like it obviously would, or unless this is a fairly recent (within the past year or so) change, and I'm just not caught up to speed on things.

But yeah. Unless we can figure out a solution to the replacement of core JS files that are incompatible with later versions problem, I'm afraid this one's going to have to end up in the "won't fix" bucket. :(

I couldn't use this on some sites due to privacy restrictions. But I like the idea as an option; theoretically having google serve a js file is superior if there's a chance a user has already visited another site using the same file, and assuming google's cdn is on average faster than your own server. Btw re: #6, drupal doesn't gzip javascript, though it can easily be done in the apache config (mod_deflate).

Don't forget about javascript preprocessing. There is a performance penalty for for each added javascript file added to a page. When a browser finds an external javascript file it stops what it's doing to process it. This is because this file may change the page and needs to be processed before moving on. Since we already have a drupal.js loaded in the page and what ever other files we are likely going to have a larger page load time from separating jquery.js out of the preprocessed file.

In any case it seems not ready for prime time. Doesn't work with HTTPS: http://code.google.com/p/google-ajax-apis/issues/detail?id=39

And it doesn't even gzip encode! (at least not when I tested with curl --compressed --head http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js)

In looking into this I noticed that drupal_get_js() doesn't deal with js files that aren't local. It adds base_path() before it calls the path. That could cause issues. There is an issue open against D7 in an effort to fix this.

When #91250: JavaScript Patch #4: External Scripts gets into core we can add this to the D7 branch.

HTTPS cert errors have been fixed. Gzip is only sent to User Agents known to support Gzip, Firebug reports they are gzipped.

Looks to me like all the issues blocking this patch have been resolved. Any reason not to get this option into 6.x-2.x-dev release?

I suggest we also take advantage of jQuery UI library right here, while we are at it.

This causes obvious problems with local file aggregation of JS files though, right...?

@NikLP: These external files must be made exempt of aggregation.

Making the files external is probably ok for development, but as Webchick rightly says, this means the site is then dependent on the 3rd party server, which has no SLA for delivering those files. As such, it's probably a better idea to just aggregate your required version in with the rest of the drupal stuff, surely?

No it is BAD idea to aggregate these libraries with everything else. Why would you do this? This adds nothing to what can be done already.

Google does not go down. The point of including libraries hosted by them use them as CDN for standard components.

Nothing to aggregate with anything here.

"Google does not go down"?? That's a joke. Massive parts of google went down just the other week for like two hours.

This is just adding request times, unless it can be proven that a) the host can be guaranteed and b) the parallelism thing is actually helpful in this context.

Google (or any other CDN) is less likely to go down than your site :)

In any case, that is a moot point. This feature is not for those who do not like 3rd party CDNs, but for those who see the value of having this option.

Let's table this debate unless you have any constructive suggestions.

This patch doesn't seem to work against the current 6.x-.2.x-dev, but I think it's worth integrating with the module (or making available to Drupal by other means). Is there any interest in including support for Google AJAX Libraries API? I'll be happy to provide a new patch.

Here's an updated patch against the current dev. Upon further thinking, I believe this would be more properly refactored into its own module which would add options to the performance page, but since this was already extant, I've supplied the updates here.

And here's an initial module that does exactly that - after all, this functionality isn't really a "jQuery Update" but a performance enhancement (in the eyes of some, at least). Maybe I'll get someone to create a project for this. I'm not a fan of CVS, so I'm not sure I'd like to be a maintainer...

Yes, I've been working in some sites which got millions of page views. Hosting jquery on Google CDN increase the performance a lot. Hosting file on CDN is definitely faster than your own site considering the server power so it's really a significant performance boost instead of penalty.

#525436: Configuring jQuery Update to use jQuery via Google CDN is a duplication of this

Can we get this thing committed and have as a configurable option?

http://drupal.org/node/610482#comment-2571822

2 Things.

1. Microsoft has a CDN as well. This should be an option. Details at http://www.asp.net/ajaxlibrary/CDN.ashx.
2. Version 2.x of jQuery Update is for jQuery 1.3.2. That needs to be reflected in any patch.

This would be a nice feature to have.

Subscribing.

Also, note michaek's http://drupal.org/project/google_ajax_api and budda's plea #863748: Merge with jquery_update project?. Kind of a feedback loop here!

I would definitely use this option if it was available. In terms of the reliability / privacy concerns, we'd be letting the administer decide if they are willing to rely on a third party.

Google sets the expiration to 1 YEAR in the future, so odds seem quite high a visitor will have it cached.

The loss of aggregation doesn't matter - aggregation primarily addresses the latency caused by many serial requests over non-pipelined HTTP (and it saves a few bytes on headers). Since the google request is to an external domain, the browser will open an additional connection in parallel and this wouldn't be expected to increase latency.

I've attached a patch for Drupal 7.x-2.x-dev version. It adds another fieldset in performance where you can choose to use an external CDN hosted library and supply the url of the library (defaults to Google's) so you can choose to use a library hosted by Microsoft if you want. If you don't choose an external library it will fall back to using the jquery_update version. One possibility might be to include a choice of libraries as radio buttons instead of allowing the user to enter the url. Allowing the url to be entered allows for any version of jQuery to be used which may be against the design decisions of jquery update.

Let me know what you think. Oh, quick note to say that you can see it working on my personal Drupal 7 powered site: http://tanc.me

I've switched over to the module posted in #24, but I would love to see it incorporated into JQuery update instead. I have several modules that have it as a dependency.

Hi I am new and would like to use Google Ajax API slideshow I downloaded the file in #24 but it does not seem to be a module I could enable. Any help with this? thanks

Can someone review my patch in #32 and tell me if its aiming in the right direction? Its been a few months now...

For anyone interested in jQuery 1.5.1 in Drupal 7... see the 7.x-2.x dev work. http://drupalcode.org/project/jquery_update.git/commit/deb3fe5.

Next up is jQuery UI from a CDN.

I'm not sure if this is still the case, but the last time I tried using Google's AJAX API I found that it did nasty things like using document.write() which is incompatible with Content-Type: application/xhtml+xml. That doesn't mean that using a CDN for jQuery would be bad -- in fact, I'm sure every browser already has a cached copy of most jQuery versions from Google's CDN because of how prevalent it is.

Now that I look at the patch from #32, I see that this bug is actually a request just to use Google's CDN and not its API, updating title...

Drupal 6 reached EOL (end-of-life) on February 24, 2016.