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.

Guest Post on Digging into WordPress

Jeff and Chris have been kind enough to publish Hosting Client Sites on a WordPress Network as a guest post on Digging into WordPress.

Regular updates keep WordPress secure and expand the feature set, ensuring the platform meets both the developer’s and their client’s needs.

The flipside of regular updates is the maintenance of WordPress installs. Once you start maintaining more than a few installs for your clients, keeping both plugins and WordPress up to date can become a bit repetitive.

Setting up a WordPress Network, using the multisite feature, reduces maintenance time. Upgrading all your sites becomes almost as easy as upgrading it for one.

Head over to Digging into WordPress to read the post and leave a comment.

Categorized as Quick Notes

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') +
  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:


Soupgiant WordPress themes on Github

Update: We’ve released our updated framework and renamed it the Big Red Framework.

The Soupgiant base WordPress themes are now available on GitHub. There’s no documentation at this stage, I’ll write up a blog post with details in the coming weeks.

There are two parts to the theme

  • Soupgiant Parent Theme
    We use this as the parent theme across multiple projects. Any bug fixes or new features applied to this theme will be available to all child themes.
  • Soupgiant Child Theme
    Starting point for each project. Once duplicated for the project, CSS styling and per project PHP customisations are applied/overridden in the child theme. Most projects require a custom header.php & footer.php.

As I say, documentation to come.