Google Libraries API

Google Libraries API now serves common libraries like Dojo and jQuery all minified and gzipped and ready to go. Yahoo has been doing this with YUI for quite a while now and AOL with Dojo.

The idea is that if enough sites are using the centralized Google libraries then when a user arrives to your site there is a chance the library is already cached in the user's browser. This saves your server some bandwidth and means the page loads faster for the user. All engineering ideas have pros have cons.

Is minifying and gzipping common library files a burden? No because you have to do it for your page-specific files anyway.

Are you really going to save much bandwidth? In the work I do, as the user travels around the site, the common libraries account for a very small portion of the overall JavaScript downloaded. The page specific code grows in comparison to the common libraries with every page visited.

Is the page really going to load faster? If you serve the JavaScript file from your own server then you can take advantage of HTTP persistent connections where the browser loads all files needed for a page with one connection. Making connections is an expensive part of downloading a page. If a third party is serving part of your page then another connection needs to be made.

Will the file really be cached because another site is using the file? To start, Google is offering 8 files. With URLs ending in jquery/1.2.6/jquery.min.js. it appears they will be retaining various versions of each library as the libraries make new releases. This will avoid breaking your page by upgrading the JavaScript. Unfortunately as the number of versions and files grows, the chance that a particular file is already cached decreases. If Google and AOL both have "central" Dojo repositories then they are not really "central" and this reduces the performance of the overall idea. Caches are not infinite in size. If a user did happen to have the cached file from Google, it may have been purged due to caching content from all the sites the user has visited between that site that cached the JavaScript file and your site. Optimistically, at least for now, perhaps 1% of your visitors won't need to download what amounts to less than a medium-sized gif worth of JavaScript for the first page they visit on your site.

What if Google's server's go down? It is probably more likely that your servers go down but why add an extra point of failure? If your page is loading, then you know your server is up and getting the JavaScript from your own server is an almost certain success. If the page is loading you don't know if Google's server is up. If you think the bandwidth savings to your server are really worth it then you could use a back-up plan.

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
  if (!jQuery) {
    // load from your own server
    document.write('<script type="text/javascript" src="/js/jquery.min.js"><\/script>');
  }
</script>

The above snippet also buys you forgiveness from the boss if Google shuts down the service or stops supporting a particular version that your 100 000 legacy pages use 5 years from now.

Will users notice that multiple servers are involved? Google is serving the shared files with http:// so if your page is https:// then users may see a "this page contains both secure and insecure items" alert. This concern may not apply too frequently but it does not help gain user trust with sharing their credit card number if that is your objective.

What is Google doing with data about your users? If Google is serving JavaScript for your page then Google has access for cross-site scripting attacks against you. I really don't think they would be doing anything like that. But what does Google do with the request headers? Are your users aware that Google is watching? Perhaps this is not such a threat on public facing pages. You may already have Google Adsense or Analytics on those pages. On the other hand, for pages behind login where user data should be protected it is better to keep only the necessary parties in the know about user activity. System administrators and server-side programmers are paranoid about security and work hard to protect it. Loading JavaScript from another server means the client-side programmer (you know, the one they think doesn't know anything and can't be trusted to build secure pages) is basically blowing all the hard work by others on the team. I'm not saying Google is malicious but I doubt a system administrator would smile when told he looses security as a trade for a few kilobytes of bandwidth.

Even though there are potential advantages to using a shared third-party JavaScript file, the argument is not weighted extremely heavily in favor of the pros. The cons are quite compelling. I don't see a net gain by using a shared JavaScript file on someone else's server. If you do, then please, by all means, enjoy.