Save Bandwidth by Serving jQuery, MooTools, Prototype via Google’s AJAX Libraries API
A great way to save bandwidth is to take advantage of Google’s AJAX Libraries API to serve your favorite open-source JavaScript libraries. Here is how Google explains it in their official documentation:
The AJAX Libraries API is a content distribution network and loading architecture for the most popular open source JavaScript libraries. By using the
google.load()
method, your application has high speed, globally available access to a growing list of the most popular JavaScript open source libraries.
The AJAX Libraries API provides your applications with stable, reliable, high speed, globally available access to all of the most popular, open source JavaScript libraries. Your application can use our very flexible loader
google.load()
, or direct, path based access to the scripts.
Usage
There are two different ways to include JavaScript from Google’s network. The first is to simply link directly to the document via <script>
element, just like you would when hosting the file on your own server. For example, to include the most recent (compressed) version of jQuery from Google, we write:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
The second way to include JavaScript from Google’s network is to use Google’s google.load()
method. Google recommends this as the “most powerful way to load the libraries,” offering “the most functionality and performance.” To use this method, you simply name your preferred JavaScript library and desired version number, and include the method at the bottom of your <body>
element:
<script type="text/javascript">
google.load("jquery", "1.2.6");
</script>
Here is a complete list of available libraries (current as of 11/25/2008):
google.load("jquery", "1.2.3");
google.load("jqueryui", "1.5.2");
google.load("prototype", "1.6");
google.load("scriptaculous", "1.8.2");
google.load("mootools", "1.2.1");
google.load("dojo", "1.2.0");
google.load("swfobject", "2.1");
google.load("yui", "2.6.0");
Note the syntax used here:
google.load("[name of library]", "[version number]")
Name of library is a no-brainer; the version number is more flexible. The google.load()
versioning system enables as much precision as needed. Specifying a full version number (e.g., 1.2.3) will load the exact version; specifying a partial version number (e.g., 1.2) will load the most recent version available for that particular branch. This logic also applies when loading the scripts directly via <script>
elements.
Available JavaScript Libraries
Here is a current list (as of the time of this writing) of JavaScript libraries available from Google’s distribution network. All of these libraries are available via either inclusion method (i.e., google.load()
or <script>
). For more information, or to check out a current list (with current version numbers, etc.), visit Official Developer’s Guide. This list is current as of today, Nov. 25th, 2008:
jQuery
- script name: jquery
- versions: 1.2.3, 1.2.6
- load request:
google.load("jquery", "1.2.6");
- uncompressed:
google.load("jquery", "1.2", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.js
- script site: http://jquery.com/
- note: 1.2.5 and 1.2.4 are not hosted due to their short and unstable lives in the wild..
jQuery UI
- script name: jqueryui
- versions: 1.5.2
- load request:
google.load("jqueryui", "1.5.2");
- uncompressed:
google.load("jqueryui", "1.5", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.2/jquery-ui.min.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.2/jquery-ui.js
- script site: https://jqueryui.com/
- note: this library depends on jquery. before loading this module, you must load jquery e.g.:
google.load("jquery", "1.2");
google.load("jqueryui", "1.5.2");
Prototype
- script name: prototype
- versions: 1.6.0.2, 1.6.0.3
- load request:
google.load("prototype", "1.6.0.3");
- script path:
http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js
- script site: http://prototypejs.org/
script.aculo.us
- script name: scriptaculous
- versions: 1.8.1, 1.8.2
- load request:
google.load("scriptaculous", "1.8.2");
- script path:
http://ajax.googleapis.com/ajax/libs/scriptaculous/1.8.2/scriptaculous.js
- script site:
http://script.aculo.us/
- note: this library depends on Prototype. before loading this module, you must load Prototype e.g.:
google.load("prototype", "1.6");
google.load("scriptaculous", "1.8.2");
MooTools
- script name: mootools
- versions: 1.11, 1.2.1
- load request:
google.load("mootools", "1.2.1");
- uncompressed:
google.load("mootools", "1.2.1", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/mootools/1.2.1/mootools-yui-compressed.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/mootools/1.2.1/mootools.js
- script site: https://mootools.net/
Dojo
- script name: dojo
- versions: 1.1.1, 1.2.0
- load request:
google.load("dojo", "1.2.0");
- uncompressed:
google.load("dojo", "1.2.0", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js.uncompressed.js
- script site: https://dojotoolkit.org/
SWFObject
- script name: swfobject
- versions: 2.1 (current)
- load request:
google.load("swfobject", "2.1");
- uncompressed:
google.load("swfobject", "2.1", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/swfobject/2.1/swfobject.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/swfobject/2.1/swfobject_src.js
- script site: http://code.google.com/p/swfobject/
Yahoo! User Interface Library (YUI)
- script name: yui
- versions: 2.6.0
- load request:
google.load("yui", "2.6.0");
- uncompressed:
google.load("yui", "2.6.0", {uncompressed:true});
- script path:
http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/yuiloader/yuiloader-min.js
- uncompressed:
http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/yuiloader/yuiloader.js
- script site: https://github.com/yui/
Taking advantage..?
This is a relatively new service provided by Google. I am interested in whether or not you are taking advantage of it. I have heard reports of many gigabytes of saved bandwidth thanks to Google’s AJAX Libraries API. What about you? Are you planning on using it? Already using it? Share your experience with performance, reliability, bandwidth, or other aspects. It’s fascinating..
Chillz! :)
18 responses to “Save Bandwidth by Serving jQuery, MooTools, Prototype via Google’s AJAX Libraries API”
Thanks for sharing this piece of really useful information :) this will definitely help a lot of people out there who have a strict host when it comes to bandwidth allowance. Heavy libraries like prototype and scriptaculous are big bandwidth hogs and by loading them from Google takes off a considerable amount of strain on the bandwidth ;) it’s just really thoughtful of Google!
Oh and another good thing is that what is hosted by Google is considered as a stable release and you can update to latest versions by just modifying the load request. That saves webmasters from all the trouble of updating their libraries and keeping track of new releases. How amazing!
One down side though – sometimes the script load a little slower for Asian internet users because of the congestion of the cross-pacific cable and local ISP restrictions (most of the time, locally hosted libraries load faster during peak hours and *coughs* the Dec 2006 Taiwan earthquake which snapped undersea cable optics). But that’s just a small issue… I am now seriously considering switching over to Google for the libraries!
p/s: I’m surprised that Google also hosts Yahoo’s YUI! :D teehee!
p/p/s: On a totally unrelated question, for the sliding effect on your sidebar, are there any scripts online that are compatible with prototype/scriptaculous? I poked around a little and realised that you’re using the one compatible with jQuery. Sorry, just a little curious! I might be using sliders in my next layout to save space as well – my sidebars are getting painfully, treacherously long.
You embed Youtube videos, Google cache pages, Google images, etc. One day you wake up and realize your whole blog is hosted by Google.
I like to control the content I serve, so no I don’t plan to use this service. Also, serving content that is hosted on tiers servers is like a bullet in the head from a performance point of view :)
These are the kinds of posts I love about your blog… (which is mostly all of them). Always useful, easy to understand. thanks- Renkai
Interesting service, although I think I’d be more inclined to go with a more conventional CDN like SimpleCDN if speed and such is the goal. You can then serve all your static content via CDN, not just JavaScript.
A CDN has many servers around the whole world, and will serve the user via the closest one to their physical location. That way you can ensure any static or larger files are being served as quickly as possible to every user, something most large sites end up doing. Generally a subdomain of the site is used which interfaces with the CDN.
A slightly more expensive service is Mosso’s CloudFiles CDN, which uses Limelight’s very respectable network and has significantly more servers throughout the world – including several in the far east.
The nice thing about CDNs is they’re typically charged at very competitive rates by the gigabyte, similarly to Amazon’s S3 system (although that’s a different market really). So most of the time you won’t pay very much at all, while if you get a massive traffic boost it probably won’t be that expensive anyway – overall savings are made in my experience.
You can see my use of SimpleCDN here to serve both the Flash and downloadable video:
http://www.brutallegend.net/trailers-and-commercials/theatrical-trailer-1/
And also this is completely hosted on the CDN, HTML and all (it’s a static dump, not a live WordPress installation):
http://cdn.brutallegend.net/v2.ryansgoblog.com/
Worth looking into for those who haven’t come across this kind of thing, anyway. CDNs have only recently become affordable now that Amazon has stepped in with aggressive pricing, so they’re kind of a new player in the non-professional scene.
Nice sumup! To add my two cents: We have been using the script tag based version of Query on our site forquite a while on http://sixgroups.com. I think the main benefit is, that the scripts are served minifed, gzipped and with proper expires headers, meaning they will be loaded within the blink of an eye. Moreover, if a lot of sites use it, users will often already have a version of the file in the browser cache. This definitely reduces your page loading times.
I favour the classic method over google.load for now, as it sometimes causes timing problems. Plus, you wont be able to have inline script blocks that make use of the libraries “onLoad stack”, e.g. you wont be able to have an inline block somewhere doing
jQuery.ready(funciton(){
//do stuff onece dom is loaded
});
as jQuery won’t be available at that point. So you will have to move all of this code to the allback funciton of google.load(), which can be quite a lot of work if your application is bigger. Thats why we stick with the script based version and we love it.
If they only hosted all the jQuery plugins too…
I always try to take advantage of CDN hosted JS libraries in all my projects. Especially ones that are just code examples. YUI has been offering hosting of their library for quite some time now.
I would say the savings on bandwidth is eclipsed by the speed, availability, caching and correct serving of versioned-static-resources Google’s and Yahoo’s CDNs provide.
As louis said I assumed serving offsite files would be a performace hit even if they are from the uber serves of google (i mean their tracking js leaves a performance optimisation need).
Though from the CDN perspective as has been mooted above…it would be inersting to see a ‘global’ speed test of local JS served and Google CDN served JS.
Then we cn decide is the speed tradeoff wrth the bandwith cost? (even though bandwith is realtivly cheap with hosting…mostly unlimited).
@Donace: yes indeed, it would be really cool to have some real world company collecting data and share the study with us!
@teddY: Sorry for the delay getting to the comments on this post! It is great to see you again, thanks for taking the time to drop in and respond to the article. I think it is very interesting to hear about the slowness of the Asian pipes due to congestion, local ISP restrictions, and the broken undersea cable optics. What a trip..
To answer your question, though, I was not able to locate any decent slider scripts for the Prototype library. There are several available for jQuery, however; I ended up using a highly customized version of Niall Doherty’s jQuery Coda-Slider (404 link removed 2017/01/22). It works great, and I intend to write up a complete tutorial on its implementation just as soon as my relentless schedule lets up a little. ;) Btw, any reason you are not using jQuery?
@Louis: I completely agree on your point about hosting content through third parties. I try to keep my dependence on external resources down to a minimum, but for certain things, such as imported Tumblr and Twitter feeds, Gravatars, and of course Feedburner, I think the benefits outweigh the risks. I have yet to take advantage of Google’s Ajax API hosting, but I am certainly considering it..
@Renkai: Thank you for the kind words! You made my day :)
@Ryan Williams: Thanks for the wealth of information of CDNs! I can see that I am actually quite inexperienced when it comes to using them, but I am thinking about giving SimpleCDN a try. Based on the examples you provided, it looks blazingly fast; so if the cost is reasonable, I may be using it for an upcoming multimedia project. Btw, that Brutal Legend trailer is insane! ;)
@Andreas Stephan: Thanks for sharing your experience with Google’s AJAX Libraries API. As you say, the fact that the scripts are served minified, compressed, and with the proper expires headers (plus the fact that many people will already have a cached version available) makes it an excellent way to speed things up and save bandwidth at the same time. As for the call method, I also prefer the traditional method, for reasons of simplicity, uniformity, and functional consistency. Thanks for the concise overview — it certainly helps reinforce my thoughts on the service.
@Eric Ferraiuolo: Well said — I couldn’t agree more. Thanks for the input!
@Donace: From previous comments, I am gathering that performance is actually improved when using Google’s CDN.. As for bandwidth savings, I would imagine that the cost-effectiveness of using a free CDN would increase along with the size and/or popularity of the site. I also agree that some real data comparing local versus centralized distribution would be remarkably useful, perhaps enough to convince some of the naysayers that the benefits outweigh the potential risks..
@Jeff: Oh thanks for the reply! I should be the one apologising because a few days after I’ve posted the comment, I finally found a prototype/scriptaculous dependent glider.js code. I like the way how you’ve implemented in for your sidebar contents, as they can really squeeze in a handful of information. I would love to switch over to jQuery but it is in perpetual conflict with Prototype and Scriptaculous. It’s an either-or thing, pretty tough call. In the end I picked the latter because coincidentally, WP-Lightbox automatically loads them from the core WP installation and will be in the cache all the time – that’s why I’m stuck with it.
Sorry to let you spend so much time digging for the prototype compatible glider code! I feel so sorry about that :(
p/s: Happy thanksgiving and here’s December! I hope it’s not very cold over your place. Take care and have a great winter!
@teddY: My pleasure! I am glad you found a JavaScript slider that works with Prototype. As you say, sliders are a great way to consolidate large amounts of information, and in a visually interesting way as well. I love your new design, by the way! Your header/slider implementation is extremely inspiring! Works great even with JavaScript disabled. Well done! :)