Why You Should Let Google Host jQuery For You

Most websites these days use jQuery. For those of you who are not 100% sure what jQuery is, below is the description as stated on the jQuery website:

“jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript.”

Like with any JavaScript file, you can host jQuery on your own web server and call it within your page, like this:

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

But there is another, better way of doing it. You can let Google AJAX Libraries content delivery network serve jQuery directly from Google’s network of datacenters. There are three main benefits of doing this: Decreased latency, increased parallelism and better caching.

Decreased Latency

A Content Delivery Network (CDN) distributes static content across servers in various, diverse physical locations worldwide. When a user visits a page serving files from a CDN, their download will automatically target the closest available server in the network which can reduce download times.

So this means when using Google’s AJAX Libraries CDN to server jQuery, users that are 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 many other CDN services available similar to this, but you will struggle to find one that’s free!

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 be downloaded in parallel. It wouldn’t make too much of a difference for someone using a browser that allows six concurrent connections, but for someone using a browser that only allows two connections the difference would be noticeable.

Better Caching

When a user visits a site, their browser will download static files so that when the user visits that page the files will not have to be dowloaded again, saving bandwidth usage, server load, and perceived lag.

No matter how well optimised your site is, if your site is hosting jQuery locally then your users will have to download it at least once before it gets saved to their cache. Because many sites use jQuery, it is likely that they will have many identical copies in their browser’s cache. 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 which will save the user’s browser from having to download it again.

How To Implement It

There are two ways in which you can implement jQuery using Google AJAX Libraries.

1.

Google recommends the google.load() approach as it offers the most functionality and performance.

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">// <!&#91;CDATA&#91;
  // 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()
  });
// &#93;&#93;></script>

Although Google do recommend this method, we have seen some performance issues, making the page loading time unnecessarily high.

2.

We actually recommend the good old fashioned <script> declaration which Google does also support.

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script type="text/javascript">// <!&#91;CDATA&#91;
  $(document).ready(function() {

  });
// &#93;&#93;></script>

You may be thinking that the http:// is missing. Using // actually is a handy little method that can actually cater for both HTTP and HTTPS.