In this article I’ll explain how to reduce the loading time of Javascript libraries using Auto-Loading, a public but almost unknown new feature of the Google’s AJAX APIs. It may looks a bit tricky, but with some patience won’t be so hard. Anyway, even Google in its official documentation says “This advanced feature can be difficult to implement, depending on the exact situation. Therefore, we recommend that auto-loading only be considered in specific cases when a reduction in latency is crucial.”
Well, crucial or not I think any kind of websites, from an home-made blog to a critical company’s website, will enjoy shorter loading time.
Let’s start
Let’s say in our website we use jQuery and Google Map API. Normally our code looks like this:
<head>
<!-- jQuery 1.3.2 -->
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
</script>
<!-- Google Map API V3 -->
<script type="text/javascript"
src="http://maps.google.com/maps/api/js?sensor=false">
</script>
</head>We could also write the same like this:
<head>
<!-- Google's AJAX APIs -->
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("maps", "3", {other_params:"sensor=false"});
google.load("jquery", "1.3.2");
</script>
</head>Ok. These are both good ways, but our aim is to reduce loading time as best as possible. This means that everything has to be loaded with a single call. Just one call for ALL our needed libraries.
Using the Auto-Loading feature
First of all we have to write a small configuration script to let Google know what libraries we need. Depending on your need it could be a bit tricky. Fortunately Google gives a free configuration wizard, but unfortunately it currently supports only some main Google libraries, and no external one. For example there’s no jQuery. Too bad. This means we have to write our configuration script by hand. At least it helps us to understand better how thing works.
Ok, as wrote above in this example we use jQuery and Google Map API, so here is what our configuration script looks like:
“modules” : [
{
"name" : "jquery",
"version" : "1.3.2"
},
{
"name" : "maps",
"version" : "3",
other_params:"sensor=false"
}
]
}
Quite self-explanatory. We are saying we need two modules, the first one is jQuery version 1.3.2, the second one is Google Map API version 3 (note: the sensor parameter is mandatory, so we must declare it, even if false).
Good, now we have to compress it:
{"name":"maps","version":"3",other_params:"sensor=false"}]}
Due to formatting you see the code splitted in two line, but please consider everything must be on one single line
Now we have to URL encode it: (you can use any free service, like this one)
%7B%22modules%22%3A%5B%7B%22name%22%3A%22jquery%22%2C%22version
%22%3A%221.3.2%22%7D%2C%7B%22name%22%3A%22maps%22%2C%22version%22%3A%223%22%2
Cother_params%3A%22sensor%3Dfalse%22%7D%5D%7DAnd finally we can add this very long string to our HTML:
%22%3A%5B%7B%22name%22%3A%22jquery%22%2C%22version%22%3A%221.3.2%22%7D%2C%7B%22name
%22%3A%22maps%22%2C%22version%22%3A%223%22%2
Cother_params%3A%22sensor%3Dfalse%22%7D%5D%7D”>
Done! If now we load our webpage everything will be there, jQuery and Google Map API, with only one call, as fast as possible. And obviously in the configuration script we can add as many libraries as we need, at the end will always be a single call in our HTML. How cool is that?
Any mistake?
To trap any mistake in the configuration script, we can take a look at the Google's response, it will tell us "Error: Invalid autoload". It can be tracked with the Firefox's Error Console, or simply go to the url and see its content, if there's something like var error = new Error("Invalid autoload."); it means you have done some mistake in the configuration script.
Going Forward
What if we go forward to the initial aim of the Auto-Loading feature? Can we use it for more then reduce our website loading time? Maybe yes...
Think this scenario. A complex website where there's only one main global javascript loading script ('cause we don't want to handle tens or hundreds loading scripts spread in every single HTML file! We want / need one single entry point, easy to maintain, easy to update). Every page called need different libraries. One jQuery, another one the Feed API, another one jQuery + Google Map API + Language API to provide a translation service to our end users. It could be a little hell.. (think this in a very complex web application). We could use the Auto-Loading feature to simply our life. We can add some custom metatags to each HTML file with informations about which Javascript library it needs to run, and build runtime a dynamic configuration script to load everything needed!
by
Senior Web Developer and JS Ninja based in London. He also enjoys mobile programming, photography, playing drums and pubs. He is the founder of the 

December 1, 2009 at 2:46 pm
Great post, will definately look at this as a lot of my apps load lots of Javascript libraries and I do tend to use multiple calls, so thanks. Will check it out.
December 1, 2009 at 2:55 pm
One of the major benefits about using Google Ajax Apis is that as more sites use the same script, there are more possibilities that the script is already cached in the browser (so, no loading times at all).
The autoloading feature seems interesting but lacks that. It should be used wisely.
December 2, 2009 at 1:54 am
I’ve just did some testing with loading this way and don’t see much difference when caching is turned off. I did 3 runs on both:
Loading in separately from google: 251ms, 281ms, 330ms
Loading in via google.load(): 334ms, 360ms, 347ms
Loading in via autoload: 366ms, 346ms, 393ms
I think the main advantage of a script being cached from another website is gone, when using the autoload feature, because the chances are pretty high that nobody has used exactly the same autoload config as you. So only if you want to load in a massive amount of libraries, this will become useful. But based on the fact that the hash configuration is so obscure to maintain, I would stick with loading the libraries separately from Google.
If anyone’s interested, my test files can be found here: http://radikalfx.com/files/jsload/
December 1, 2009 at 2:56 pm
Francesco, thanks for this useful tips!
December 1, 2009 at 3:07 pm
Isn’t loading JS in the HEAD section a bad idea from a performance perspective? As I recall the general rule is to load CSS as early as possible and JS as late as possible (meaning just before the close BODY & HTML).
December 1, 2009 at 8:51 pm
ya, thats that i was thinking too :) most of the sites i developed has their CSS on the top and later on followed by the rest of the codes, thanx Francesco…this info is really helpful :)
December 2, 2009 at 12:54 am
Interesting article.
One thing, in the very long string you’re missing a question mark; “jsapiautoload” should be “jsapi?autoload”.
December 2, 2009 at 1:59 am
Unlike what I read here and everywhere, I don’t use the google hosting for jQuery and I think it’s a bad practice.
Google can be slow or down (yes, of course it could !). If the website that you visit can load a page, so it can also load the tiny 19KB jQuery file.
December 4, 2009 at 10:40 am
Loading JavaScript libraries from Google provides two benefits. First, Google acts as a CDN for the JavaScript files: that means you get things like parallel downloads and faster distributed downloading for the client (the file is served from a server closest to the client). Second, the JavaScript files get cached on the client’s computer. This of course happens whether served from Google or not, but browsers handle caching based on domains. In other words, a person could go to 20 sites all using the same version of jQuery and potentially end up with 20 copies of the jQuery library cached on their computer. That just doesn’t make sense. If those 20 sites all serve jQuery from Google, though, the client downloads only once and the subsequent 19 sites get a performance boost.
December 2, 2009 at 8:45 am
Just so everyone isn’t confused this doesn’t decrease the number of script loads to a single call. In reality is actually INCREASES the number of call by one.
The script that is loaded is just a “loader” and still calls each individual library using dynamic script tags or whatever. So if you were loading jquery and maps in two separate calls, you’re now loading three scripts: the loader, and then jquery and maps.
The article is a little misleading as it infers that all the libraries are merged into one result when they are not.
December 2, 2009 at 8:55 am
Also, it’s important to use the callback methodology outlined in the Google docs. You can’t, for example, include jQuery this way and then use the document loading functionality:
$(document).ready(function() {
// put all your jQuery goodness in here.
});
If you try to do this jQuery may not be loaded yet when the method is executed.
December 2, 2009 at 9:44 am
I do like this feature, but I rely on the fact that many sites use Google’s API already, so it’s already cached.
Scripts in the head is a really nit-picky thing. The majority of my users are using broadband and I offset much by lazy loading and keeping my http request to a minimum.
Hosting with Google is not a bad practice… as a failsafe, I check it jquery is defined, if not, I render the jquery library from Microsoft’s CDN. :)
pretty good chance that BOTH won’t be down. :)
January 17, 2010 at 7:29 am
This is pretty cool. Have you play around making your own wizard? This concept is good but I prefer to host the wizard in-house as opposed to using Google.