Unlike James Collins, we don’t have terminal access to any servers in Australia. As I’ve detailed before, our sites are hosted in the US. James was kind and diligent enough to do some further testing comparing Microsoft’s CDN to Google’s. He found they resolved as follows:

If you have the chance, I’d love you to test where ajax.aspnetcdn.com and ajax.googleapis.com resolve to for you. You can do a
traceroute

and you should be able to work out the destination from host names and response times. Letting me know via twitter is probably easiest, my username is @pwcc.

Obviously, I should have done all this checking before writing the post. By failing to do so, I look a bit of a tit.

Over on Twitter @bobearth, prompted me to run some trace routes against the Google CDN and compare it to the Microsoft CDN. It appears Google have taken the distributed network out of their CDN.

As you’re probably aware, CDN is an abbreviation for content distributed network. The idea behind them is that American users will be served content from a server located in the US or Canada, Australian users will be served content from a server located in Australia or the Pacific, and so on.

Doing a trace to the Google CDN from the Soupgiant HQ in Melbourne, I was expecting to receive a response a server in Sydney. Instead, the response came from California, USA as the final steps of this traceroute show:

127.0.0.1:~ peterwilson$ traceroute ajax.googleapis.com
[snip]
 5  syd-nxg-men-crt1-ge-3-1-0 (202.7.173.241)  27.479 ms  87.472 ms  78.234 ms
 6  202.7.171.46 (202.7.171.46)  91.118 ms  31.786 ms  27.314 ms
 7  66.249.95.232 (66.249.95.232)  80.358 ms
    66.249.95.234 (66.249.95.234)  27.842 ms
    66.249.95.232 (66.249.95.232)  44.059 ms
 8  209.85.249.52 (209.85.249.52)  177.570 ms
    66.249.95.166 (66.249.95.166)  172.656 ms  157.311 ms
 9  72.14.236.126 (72.14.236.126)  172.117 ms  153.304 ms  180.227 ms
10  googleapis.l.google.com (66.249.89.95)  178.725 ms  193.939 ms  181.227 ms

The response from Microsoft’s CDN were more to my liking:

127-0-0-1:~ peterwilson$ traceroute ajax.aspnetcdn.com
traceroute: Warning: ajax.aspnetcdn.com has multiple addresses; using 70.37.159.166
traceroute to ajax.aspnetcdn.com (70.37.159.166), 64 hops max, 52 byte packets
[snip]
 7  10gigabitethernet5-1.syd-xmx-edgcom-1b.ntwk.msn.net (70.37.149.62)  90.691 ms  86.004 ms  37.900 ms
 8  ajax.microsoft.com (70.37.159.166)  71.541 ms  83.053 ms  80.586 ms

This prompts the question: should I switch to serving jQuery and other hosted libraries to the Microsoft CDN? Both Google and Microsoft use a cookie-free domain for their CDNs, both are set to browser cache for 12 months. More sites use Google’s CDN to serve, but only Microsoft serve geographically near the majority of visitors to Soupgiant and Big Red Tin.

I don’t know the answer to this question. I do know that if Google’s CDN was distributed, there would be no question.

The cheat notes are that three different URLs point to the current edition of jQuery and each URL is cached in the browser for a different length of time:

• Latest in the version 1 tree: 1 hour
• Latest in the version 1.4 tree: 1 hour
• Version 1.4.2 exactly: 1 year

The point of my post was that, when using Google’s AJAX Library to host jQuery, or any of the other libraries, it is best to specify the exact version to receive the full benefit of hosting on the same server as gazillions of other web sites, that being, your visitors don’t need to download the library for every site they visit. I was reminded of this when Dave Ward appeared on episode 32 of the official jQuery podcast.

When jQuery 1.4 was released, the Google URL being publicised by the jQuery team was http://…/jquery/1.4/jquery.min.js – while Google had set it up as http://…/jquery/1.4.0/jquery.min.js. I had two problems with this:

• The publicised URL, coming from the official jQuery team, was only cached for 1 hour;
• Anyone using the publicised URL would automatically be upgraded to jQuery 1.4.1 upon its release, regardless of their expectations.

My request to John Resig and the jQuery team is to avoid confusion by officially numbering the next version as jQuery 1.5.0 and publicising the URL that contains the full version number.

That means that for most people the default version of jQuery they download will be updated least often. It means that the people building the websites have more control over which version of jQuery their end users download and when.

It may seem trivial now but if your visitors leave your site while they’re waiting for jQuery to download, you’ll think it less so.

I’d love to hear your thoughts in the comments below or via @bigredtin on Twitter. If you agree, why not let the jQuery team know via Twitter.

Update: In the blog post announcing version 1.5, the jQuery team did publicise the 1.5.0 URL on the Google CDN.

I could have used an existing frame work, such as the increasingly popular jQuery; I decided to use my own, which contains only the very basics, rather than have a larger file containing rarely used functions

–source (emphasis added for this post)

Within a couple of months of writing that, I was a convert to jQuery. There was no single reason for my conversion, from memory some of the reasons where:

• the selector engine,
• plugin availability,
• documentation — both official and unofficial tutorials, and,
• lazyness

It’s the last one that probably had the biggest influence, I’m too lazy to reinvent the wheel, and without using a framework that’s what I was going to be doing. Frequently. Examples in blogs I read, weather it be group blogs, such as A List Apart, or one person shows, such as CSS-Tricks were all beginning to use jQuery. If I were to stick to my guns and not use a framework, I’d be doing a lot of rewriting.

As for the functions that are rarely used? It’s really only the Ajax group of functions that I’ve never used, for the simple reason that I don’t like Ajax. In many of the situations it’s used, it is often fanciness without necessary function. Then again, ask me about Ajax in a couple of months’ time.

1. http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js,
2. http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js, and,
3. http://ajax.googleapis.com/ajax/libs/jquery/1.3.0/jquery.min.js

The first uses the latest release in the version 1 tree, the second the latest in the version 1.3 tree, and the third the release 1.3.0 exactly. What I found interesting – and discovered accidently – is the browser caching times for each of these urls; the first two are cached for an hour, the third for twelve months.

The vastly different caching times make perfect sense, in the first two cases, the developer is expecting an upgrade to the latest version, and doesn’t want to wait up to twelve months for it; in the third case the developer doesn’t expect an upgrade so an extended caching period has no effect.

To take full advantage of the Google servers, as described in a recent article by Dave Ward, the caching times suggest it’s best to specify the full version of the library you wish to use.

google.load Method – Update Jan 24, 2009

Further investigation shows that the Google load method uses the full URL for the less specific version requests, for example the following will load ajax.googleapis.com[...]/1.3.1/jquery.min.js* ? at the time of writing ? and cache the file for twelve months.

<script src="http://www.google.com/jsapi"></script>
<script>
  /* <![CDATA[ */
  google.load("jquery", "1"); //latest version in the v1 tree
  /* ]]> */
</script>

The jsapi file is not cached, so a additional 5K is downloaded for every page hit on your website; if a visitor loads more than three pages an hour then the advantage of the longer caching time is lost. As always, it’s a matter of compromise.

* A minor update to jQuery has been released since the original article was written.