Google is a wonderful creature. Once the champion of the meek and “Do No Evil” standard bearer of the world, it has long since grown into a huge moneymaking behemoth that seeks to control every aspect of our forages into the online world.

However, no matter how much you dislike just how Microsoft-like they are becoming, they do have a lot of stuff that you want – like all their awesome, localized datacenters for example.

And just why would you want to make use of their awesome datacenters and data shifting capabilities then?

Well for a start, they can certainly help speed up delivering your jQuery-powered websites to the masses! Just think about it. Normally you simply host the main jQuery library script on your own webserver and link your webpage directly to it. However, there is a price to be paid here, and that is naturally the time it takes to download the jQuery script and use it accordingly. So how does Google help us reduce this for our public-facing websites then?

Well the first advantage of using Google to host the jQuery script is the decreased latency that comes with using Google’s content delivery network (CDN). Now CDNs usually work by distributing your static content across a range of diversely situated servers which then serves up whatever file the user requests from the server that is located closer to the user – in other word it technically should reach the user much faster. Now say for instance your webserver sits in the United States and a user accesses it from South Africa. Seeing as Google as a server sitting closer to the user means that a request should reach him faster by using the Google server rather than the native server all the way back in the States. Needless to say, with Google’s huge worldwide footprint, I’m pretty sure you can see what I’m implying.

Secondly, using an alternative source for your jQuery inclusion helps speed up things in terms of parallelism. The web was designed to load asynchronously, meaning that elements are all pulled down and loaded up on their own little threads, all in order to speed things up a little. However, in order to avoid throttling a server, most browsers restrict the number of concurrent connections that can be made to any particular server! This throttling of server connections could be a problem if all your content is being delivered from the same server, hence it makes sense to try and distribute the load across as many different servers as what you can – in other words using Google to serve up your jQuery file comes up trumps once again.

Finally, caching could just be the biggest advantage of using Google yet. Simply put, even if the jQuery file you are serving up is identical to the one being served up by every other jQuery-enabled website out there, the fact that this file comes from different servers means that your browser is forced to download it at least once, meaning you are left with multiple copies of the same file all over your system. However, if many sites adopt using jQuery off Google’s library, this would mean that you may already have grabbed the necessary file while browsing a site other than your own, meaning your browser no longer needs to pull the script file down again – saving you an entire download chunk of time!

So no matter how you look at it, relying on the giant that is Google to serve up your jQuery for you might be one of the smartest ideas yet – though just how should you go about doing it?

Well, while Google does offer a nifty little call that determines the correct version of jQuery you are looking for and serves it up immediately, this technique does have that extra little check in it that will add a millisecond or two to the whole process, which could be a little bothersome to all you efficiency whores out there. Instead, it might be better to call the jQuery library directly using a standard <script> call, leaving us with something like this:

<script src="" type="text/javascript"></script>
<script type="text/javascript">$(document).ready(function(){
//nice! :)

Fast, efficient, and perhaps well worth taking the time to check out whether or not this implementation is faster than your old way of calling it! ;)