Monitor your systems after making changes

December 30, 2012 Link to post  Permalink

After running the code update from my previous blog post about delaying the load of external scripts I realized that something was very broken.

The code seemed to work for me, on my browser, but my Google Analytics count went almost all the way down to zero. I’m guessing that the script code just wasn’t running at all using the window.onload technique. Hooking in these events on all browsers is clearly not as easy as it looks!

I’ve bitten the bullet and added JQuery to this blog and changed the way the external scripts are implemented.

Here’s my application.js

//= require jquery
//= require jquery_ujs
//= require google_analytics
//= require hittail
//= require twitter
//= require google_plus
//= require disqus

Here’s my google_analytics.js file

$(document).ready(function() {

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'ACCOUNT-ID']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

});

Each script is now self contained for development, yet pulled into the single application.js file for production deployment. This adds a new file to my application, but this is more realistic for testing the performance of non-trivial applications in the wild.

The downside of this is that the social buttons are back to taking up the majority of the render time of each page.

Summary

When deploying an update, not only should you test that all is working, you must also monitor your diagnostics over time to ensure you didn’t break anything for large groups of users that aren’t you.