Serve JavaScript Frameworks Faster with the Google AJAX Libraries API

Tweet

Google has announced an extension to their Google AJAX APIs service: the AJAX Library APIs. They’ve assembled a collection of the most common JavaScript libraries and made them available on their content delivery network.

A common criticism leveled at JavaScript framework libraries is that the same code is downloaded from all the sites that use them, wasting bandwidth and creating duplicate files in the browser’s local cache. Google’s initiative is an effort to relieve that burden and create a kind of JavaScript Shangri La where all the frameworks hang out together, making efficient use of their time and possibly singing. if there’s a better way to ruin a decent plane-crash-survival movie than singing I haven’t seen it! Frank Capra has a lot to answer for.

Anyway, if enough sites use the Google CDN for their JavaScript libraries, the better the chance that the browser has already cached a local copy of it and can avoid having to download it again. Everyone reaps the performance benefits!.

Using the service is simple. You can directly reference the libraries via URI like so:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js">
</script>

Alternatively, you can use Google’s API thusly:

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load("prototype", "1.6.0.2");
</script>

The first argument is the name of the library and the second is the desired version.

The JavaScript that comes down the wire, is gzipped when supported by the browser (the 124K Prototype library is compressed to about 30K) and comes with appropriate cache headers. An excellent feature of the service is the control you have over versioning. The above examples download a very specific version of Prototype: 1.6.0.2. But you can specify any increment level and it will serve up the latest version. For example if you specify version 1.6 you’ll get the latest 1.6 incremental version, what ever that may be. The same happens if you specify version 1, and if you don’t specify any version you’ll get the latest version available.

However, I noticed something even niftier when doing some testing, the Cache-Control header value is adjusted to suit the request. When specifying a specific incremental version, the header value looks like this:

Cache-Control: public, max-age=31536000

This informs any caching mechanism that cares to honor Cache-Control headers that the content is safe to cache for up to a year. When a more general version is specified you get this:

Cache-Control: public, max-age=3600, must-revalidate, proxy-revalidate

This informs caches that the content should be checked for changes hourly, to ensure the latest version is delivered.

The documentation only mentions versioning in association with the google.load API call but all the following direct URIs seem to work and deliver Prototype 1.6.0.2:

Currently Google hosts:

Some of those libraries also have minified versions.

There’s a short video on YouTube explaining how it all works, but it appears to be slightly out of date; the URI used to directly access the JavaScript file doesn’t match the documentation and doesn’t work.

When announcing the API on Ajaxian, Don also said something very interesting about the future of this kind of service:

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT’d ones, from their local system. Thus, no network hit at all!

Despite the rantings of some grumpy old curmudgeons, the use of JavaScript framework libraries is only increasing and improving. I can remember in the old days of DHTML when every script available had it’s own version of the addEvent method; so much wasteful duplication of code. The availability of common frameworks has stopped the duplication and offers a useful level of abstraction. I think Google’s new service is a great step in the right direction.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • ionix5891

    so google now can datamine their access logs for more traffic data….

    sigh yet another way for google to hoard data

  • http://rollerscapes.net s.stok

    Looks very nice :)
    Only there is no support for https (yet) so secured back-offices will get an warning or no content at all.

  • http://www.mikehealy.com.au cranial-bore

    Very nice. I know Yahoo cop quite a bandwidth bill by hosting the YUI files the way they do, but I guess for the owners of YouTube anything else is totally insignificant.

  • php_penguin

    Can you maybe post a sample URL for the latest regardless of version?

    Eg with jQuery, if it goes to 2.0.0 (probably a year away) I might want my script to use it regardless.

  • logic_earth

    @php_penguin
    That isn’t too safe, you wouldn’t want to update a library/framework without first testing to make sure nothing has gone AWOL.

    But if you want to live on the edge you are going have to make your own system because google doesn’t seem to have such a thing :P

  • http://aldomatic.com aldomatic

    This is awesome, Google is so nice.. yet evil in some ways hehe :)

  • http://tetlaw.id.au atetlaw

    @php_penguin, according to the doco, you can’t. You must at least specify a major version.

  • http://tetlaw.id.au atetlaw

    Oh and I made a slight error, the documentation _does_ mention that the versioning feature works with direct URIs:

    Note, these versioning semantics work the same way when using google.load and when using direct script urls.

  • http://www.jumbocdinvestments.com chriscd

    Overall, seems helpful. And sure they have things in mind, but they are letting you use their servers.

  • http://www.ThePatio.net michael – ohio

    wihout https support, it’s fairly useless for serious websites. (and neither google, nor Y! provide SSL support for their mapping APIs either) – michael

  • spleecho

    no, google is not curing cancer with this, but it’s really awesome. whatever is done to speed things up on the web is welcome in my eyes. as a designer/developer, I can concentrate now more on the fun stuff and not worry about some of the other things as much :)

  • MisterrMc

    Great idea but I agree, https support is a must. I don’t like the distribution concept so far either. The availability should be through a P2P structure (not direct from Google only) and/or some form of an auto-update (browsing independent) schedule – but that’s another topic.

  • http://www.rmwpublishing.net/ mountainash

    What’s to stop Google adding some “extras” into script to track key presses or mouse movement? Or worse force AdWords into your site (they could do it at random).

  • Dymok

    Why you need https for getting a lib?

  • Dymok

    Also, if you think libs from google have some extra code just download the same version from lib official site and make diff.

  • dunyadata

    thank

  • Isquaretechnologies.com

    wihout https support, it’s fairly useless for serious websites. (and neither google, nor Y! provide SSL support for their mapping APIs either)