// Load the jQuery library
      yepnope([
      {
 
        // Load the jQuery library from Google's AJAX API CDN
        load: '//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js',
 
        // Determine if the local copy of the jQuery library needs to be loaded
        callback: function()
        {
 
          // If the jQuery library could not be loaded then load the local copy
          if (!window.jQuery)
          {
            yepnope('/includes/js/jquery.1-7-2.js');
          }
 
        }
 
      }
      ]);

You can download it from http://yepnopejs.com/.

I just prefer having it on my side, compressed, gzipped, and merged with other files.

Of course, some users will benefit from CDNs, but many users will feel the opposite effect.

Of course, one could insist that an off-phone host be limited to those times (normally few) when it can be loaded via WiFi, rather than via the phone’s costly non-WiFi data connection.

That could be implemented by a data source test & a decision to use the local jQuery.js file when anything other than WiFi would be used to bring it in from elsewhere.

When I first read this a couple years ago I was totally sold. Now, I’m switching back to local.

(1) PRIVACY, PRIVACY, PRIVACY. Google is evil. They really are. And if they aren’t yet, they will be. Or they will be compromised by government.

(2) I can set caching for one year also.

(3) I’ve now set up my own static domain to address parallelism and cookies.

AND THE BIG CDN KILLER…

(4) The latest server technologies automatically combine multiple .js and .css resources into one download, and minifies them and compresses them at the same time. There is now less penalty to maintaining customized jQuery and other resources locally.

GREAT ARTICLE, NEVERTHELESS! THANKS! Your arguments remain powerful ones but I think the benefits can be reasonably reaped without sacrificing privacy.

Best wishes!!!

You’re right that it’s a good idea to prepare for situations where the CDN is inaccessible, but falling back to a local copy in those situations is simple.

As for the security FUD, those doubts have been raised before, but I don’t find them credible. It’s far, far more likely that your own server will be hacked than Google’s hardened CDN. On the other hand, if the Google CDN were hacked, that would be front page news within minutes and remedied immediately, whereas orders of magnitude less eyeballs are watching the assets on your server for you. This is one case where you’re actually safer sticking with the herd, IMO.

1. It may be down or inaccessible (just google for ajax.googleapis.com and see how many ppl have problems)
2. It may be blocked by your firewall or your sysadmin
3. It may be phished for a malicious code
4. Google might decide to change the naming conventions (happened to my AppEngine site once)
5. You can not run your website on a local network

etc…

http://codex.wordpress.org/Function_Reference/wp_enqueue_script

Also, his analysis didn’t go far enough. When you confine your analysis to larger sites, it’s much more likely that they’ll have their own CDN in place and not care to use a third party. When I did something similar a couple years ago, but took my crawler all the way down the top 1,000,000 sites (by Alexa ranking), I found that references to the Google CDN increased the further down that long tail that I went. So many WordPress themes, sites using H5BP, and other starting points use the CDN reference that its coverage among all sorts of new and/or niche sites is really great.

Putting those two facts together, I stand by my recommendation to use Google’s CDN for jQuery.