Asynchronous Google Analytics Script

When Google Analytics (GA) first came out they recommended you place their tracking script (urchin.js) in the html header (with all the other javascripts on the page). Since pages are synchronous by nature, this meant all the data on the page was sent from the server to the browser in a steady stream, top to bottom. Placing the GA script in the header increased the likelihood that a visitor’s browser would load the script, but it delayed the loading of the rest of the page until after the GA script had loaded completely – sometimes adding 5-15 seconds to page load time.

Google replaced their urchin.js with a new ga.js script, and with it suggested you place the script immediately above the </body> tag, which is below all your page content. This allowed the contents of the page to load first (which appeared faster), and let the GA script load as the very last thing on the page. This method meant that the page looked like it was loading faster, but ran the risk of not tracking all visits to the page (because people might navigate away before the GA script had fully loaded).

Recently, Google has introduced a new method for loading the GA script, this time asynchronously. Asynchronous loading really came into vogue with AJAX. To oversimplify, a developer could write a page with placeholders on it. This page would load very quickly, and after it was loaded, a script would run in the browser that requested the data to be put in the place holders. Data for several place holders could be requested at the same time and take as long as they needed to load, but the remainder of the page would be visible AND usable during this time.

Google applied this asynchronous methodology to their GA script, so the page loads completely, then sends a request for the GA bits to be loaded, this happens in the background while the visitor is using the page, without impacting the visitor’s surfing experience.

Technically this method doesn’t save any time over either of the prior methods. It does, however, appear to the end-user to save time, giving the impression of increased speed.

The new code (via the Google Analytics blog) is:

   1: <script type="text/javascript">
   2:     var _gaq = _gaq || [];
   3:     _gaq.push(['_setAccount', 'UA-XXXXXX-X']);
   4:     _gaq.push(['_trackPageview']);
   5:  
   6:     (function() {
   7:         var ga = document.createElement('script');
   8:         ga.type = 'text/javascript';
   9:         ga.async = true;
  10:         ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
  11:         (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(ga);
  12:     })();
  13: </script>

Let me know how your implementation goes!

You can thank me later™.

WordPress 2.9

Wow… so that was a huge ordeal.

For those of you who care, this blog is powered by WordPress. WordPress just released version 2.9. Version 2.9 needs MyAQL 4.1.2.5 or higher (or something like that) to run. I was running 4.0.something.

So I backed up my database only to find that I couldn’t RESTORE the database. So I had to export all my posts. This worked fine for all my blogs but this one, which I had to get a more “advanced” exporter and chunk the backup (it kept “completing” but it would crap out with a timeout error, which would corrupt the XML).

Once I got all the posts/comments chunked out into 4 parts, I had to create a new MySQL 5 database, then edit all my config.php files to point to the new database. Then import the 4 chunks, then reconfigure all the blog settings.

Once I got all that done I was able to install WordPress 2.9.

Yikes. But now I’m on MySQL 5.x which should last me for a while…

That explains why things were “wonky” today. I’ve also made the decision to axe Disqus for my commenting engine. I’m going with the stock WP comments. I really dislike giving control of “my” content to a 3rd party who doesn’t work all the time (I’ve had problems with both Disqus and Intense Debate). So, if you lost your comments in the shuffle, I apologize. Please repost them and I’ll be happy to approve them.

Custom JavaScript in Microsoft Dynamics CRM 4.0

We do a lot of customizations on our Microsoft Dynamics CRM 4.0 deployment, specifically, adding buttons that run custom reports based on data provided in the CRM form (custom price quoting, etc.).

We accomplish this by modifying the isvconfig.xml file to add buttons that call JavaScript functions. For the purpose of this article I’ll assume you know how to add buttons to various forms via the XML.

Adding a JavaScript onClick event is fairly easy to add to your custom button, but wiring up the event isn’t quite as easy — unless you know this trick.

The issue at hand is that the form properties only exposes a text block for the form_onload() function, which it opens and closes outside the editable form.

Simply adding your new function inside this text block will cause an "error on page" condition and the button’s click event will fail.

To fix this we need to put the custom function(s) outside the form_onload() function, but we have to close the form_onload() function to do this. Also, we must insert a dummy function at the end of our customizations to properly close the curly braces that we prematurely closed when we closed the form_onload() function. Below is a code sample of the needed code. Please note this, by itself, is not valid javascript, but when inserted by the CRM engine, it is valid.

   1: // End the stock form_onload() function
   2: }catch(e){displayError("window", "onload", e.description);}}}
   3:  
   4: function yourCustomFunction()
   5: {
   6:     var yourParameter = "some-parameter";
   7:     var url = "";
   8:  
   9:     url = "http://yourlink.com/" + yourParameter;
  10:  
  11:     if (url != "")
  12:     {
  13:         var params = 'width=940, height=580, top=30, left=30, menubar=yes,titlebar=yes,toolbar=yes,status=yes, resizable=yes';
  14:         window.open(url,null,params);
  15:     }
  16:  
  17:     // The following is needed to properly close what was
 left over when we
  18:     // closed function_onload() in line 2.
  19:     function msft_dummy_function()
  20:     {{try{

You can thank me later.&trade

Get Adobe Flash playerPlugin by wpburn.com wordpress themes