Peter Wilson

Tag: Google

  • Putting the “distributed” in CDN

    I wrote yesterday that Google appeared to have taken the “distributed” out of their public CDN hosting of a variety of JavaScript libraries. I even provided some trace routes comparing their CDN to Microsoft’s. I was wrong.

    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:

    Location Google Microsoft
    Melbourne, AU US Sydney
    Sydney, AU Sydney US
    Perth, AU Sydney US

    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.

  • Taking the “distributed” out of CDN

    Note: After publishing this article, I was given the results of traceroutes from other Australian cities. The results showed I was wrong.

    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.

    (more…)

  • Caching Google’s WebFont Loader

    The Google WebFont Loader provides the following sample code:

    WebFontConfig = {
  google: { families: [ 'Tangerine', 'Cantarell' ] }
};
(function() {
  var wf = document.createElement('script');
  wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
      '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
  wf.type = 'text/javascript';
  wf.async = 'true';
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(wf, s);
})();

    The line in bold indicates version one of webfont.js is being loaded. As with Google’s other hosted libraries providing a more, or less, specific version number will effect both browser caching and whether the webfont.js is upgraded automatically.

    Version in code Version provided Caching period
    1 Latest in Version 1 tree (currently 1.0.17) 1 hour
    1.0 Latest in Version 1.0 tree (currently 1.0.17) 1 hour
    1.0.17 Version 1.0.17 1 year

    By using the exact version number in your code, the load time of your site will improve on return visits as webfont.js will already be cached in your visitors browser. It will be cached on your visitors first visit if they’ve visited another site using the exact version in the last twelve months.

    You can see the latest version available by visiting the Google Libraries Developer Guide. You can specify the exact version number in your code by replacing the bold line in the code sample above with:

    '://ajax.googleapis.com/ajax/libs/webfont/1.0.17/webfont.js';

  • Caching on the Google AJAX Libraries API

    Using the Google AJAX Libraries API, there are several options for specifying the version numbers of the library you wish to use, for example the following URLs all point to the latest version – at the time of writing – of jQuery.

    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

    (more…)