Using Google to Make Your jQuery Load Faster CodeUnit 04 FEB 2010

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="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">$(document).ready(function(){
//nice! :)
});</script>

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! ;)

Related Posts:

About Craig Lotter

Software developer, husband and dad to two little girls. Writer behind An Exploring South African. I don't have time for myself any more.

  • Good. please how do we go about it then ? do we have to add the codeblock above to somewhere or do we have to download something else from somwhere ?
    .-= Sam2´s last blog ..Re: Hot Chat with Hbabe =-.

  • Good. please how do we go about it then ? do we have to add the codeblock above to somewhere or do we have to download something else from somwhere ?
    .-= Sam2´s last blog ..Re: Hot Chat with Hbabe =-.

  • Nope, it’ll work perfectly fine in the header of your page. Place all jquery in the space currently marked //nice! :)

  • Nope, it’ll work perfectly fine in the header of your page. Place all jquery in the space currently marked //nice! :)

  • Zlatan Halilovic

    Nicely written.

    Tnx Craig :)

  • Zlatan Halilovic

    Nicely written.

    Tnx Craig :)

  • No problemo Zlatan! :)

  • No problemo Zlatan! :)

  • I’d say best to go with the non-automatic version selection from Google you cite in the last paragraph — that way you have more control over the upgrade path of your code (although jQuery is pretty backward compatible)…
    .-= Sven Welzel´s last blog ..KnowledgeTree 3.7.0.2 Document Indexing and Indexer issues (SOLVED) =-.

  • I’d say best to go with the non-automatic version selection from Google you cite in the last paragraph — that way you have more control over the upgrade path of your code (although jQuery is pretty backward compatible)…
    .-= Sven Welzel´s last blog ..KnowledgeTree 3.7.0.2 Document Indexing and Indexer issues (SOLVED) =-.

  • Agreed, for the most part it is a good idea to have more direct control over which you’re loading, but like you said, jQuery seems pretty solid on the whole backwards compatibility issue (those as with most things, that’s not exactly a guarantee…)

  • Agreed, for the most part it is a good idea to have more direct control over which you’re loading, but like you said, jQuery seems pretty solid on the whole backwards compatibility issue (those as with most things, that’s not exactly a guarantee…)