3 reasons why you should let Google host jQuery for you

 When using Jquery, have you ever thinking of how to make your web page or your web app load faster and faster. I used jQuery for a long time to develope our customer's web application and realized that we should to using Google Host Libraries for some reasons including decreased latency, increased parallelism and caching.  I decided to write an entry about that but when searching on the internet, I found a marvellous post below:

All too often, I find code similar to this when inspecting the source for public websites that use jQuery:

<script src="/js/jQuery.min.js" type="text/javascript"></script>

If you’re doing this on a public facing website, you are doing it wrong.

Instead, I urge you to use the Google AJAX Libraries content delivery network to serve jQuery to your users directly from Google’s network of datacenters. Doing so has several advantages over hosting jQuery on your server(s): decreased latency, increased parallelism, and better caching. In this post, I will expand upon those three benefits of Google’s CDN and show you a couple examples of how you can make use of the service.

 Decreased Latency

 A CDN — short for Content Delivery Network — distributes your static content across servers in various, diverse physical locations. When a user’s browser resolves the URL for these files, their download will automatically target the closest available server in the network.
 In the case of Google’s AJAX Libraries CDN, what this means is that any users not physically near your server will be able to download jQuery faster than if you force them to download it from your arbitrarily located server.
 There are a handful of CDN services comparable to Google’s, but it’s hard to beat the price of free! This benefit alone could decide the issue, but there’s even more.

Increased parallelism

 To avoid needlessly overloading servers, browsers limit the number of connections that can be made simultaneously. Depending on which browser, this limit may be as low as two connections per hostname.
 Using the Google AJAX Libraries CDN eliminates one request to your site, allowing more of your local content to downloaded in parallel. It doesn’t make a gigantic difference for users with a six concurrent connection browser, but for those still running a browser that only allows two, the difference is noticeable.

Better caching 

Potentially the greatest benefit of using the Google AJAX Libraries CDN is that your users may not need to download jQuery at all.
No matter how well optimized your site is, if you’re hosting jQuery locally then your users must download it at least once. Each of your users probably already has dozens of identical copies of jQuery in their browser’s cache, but those copies of jQuery are ignored when they visit your site.
However, when a browser sees references to CDN-hosted copies of jQuery, it understands that all of those references do refer to the exact same file. With all of these CDN references point to exactly the same URLs, the browser can trust that those files truly are identical and won’t waste time re-requesting the file if it’s already cached. Thus, the browser is able to use a single copy that’s cached on-disk, regardless of which site the CDN references appear on.
 This creates a potent “cross-site caching” effect which all sites using the CDN benefit from. Since Google’s CDN serves the file with headers that attempt to cache the file for up to one year, this effect truly has amazing potential. With many thousands of the most trafficked sites on the Internet already using the Google CDN to serve jQuery, it’s quite possible that many of your users will never make a single HTTP request for jQuery when they visit sites using the CDN. Even if someone visits hundreds of sites using the same Google hosted version of jQuery, they will only need download it once!

Implementation

By now, you’re probably convinced that the Google AJAX Libraries CDN is the way to go for your public facing sites that use jQuery. So, let me show you how you can put it to use. Of the two methods available, this option is the one that Google recommends:

The google.load() approach offers the most functionality and performance.

<script src="http://www.google.com/jsapi"></script>
<script>
  // You may specify partial version numbers, such as "1" or "1.3",
  //  with the same result. Doing so will automatically load the 
  //  latest version matching that partial revision pattern 
  //  (e.g. 1.3 would load 1.3.2 today and 1 would load 1.9.1).
  google.load("jquery", "1.9.1");
 
  google.setOnLoadCallback(function() {
    // Place init code here instead of $(document).ready()
  }); 
 </script>

 While there’s nothing wrong with this, and it is definitely an improvement over hosting jQuery locally, I don’t agree that it offers the best performance.

Back to basics 

In the face of those drawbacks to the google.load() method, I’d suggest using a good ‘ol fashioned <script> declaration. Google does support this method as well. For example:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>
  $(document).ready(function() {
    // This is more like it!
  });
</script>

Not only does this method avoid the jsapi delay, but it also eliminates three unnecessary HTTP requests. I prefer and recommend this method.

 HTTTypo? 

If you’re curious why the script reference is missing the leading http:, that’s a helpful trick which allows you to use a single reference that works on both HTTP and HTTPS pages. The main caveat to keep in mind when using the protocol-less reference is that it will fail on pages loaded via file:/// (i.e. HTML pages you load directly from disk to your browser). So, do be sure to include the http: protocol in the URL if you happen to be developing without a web server at all, but don’t worry about omitting it otherwise.