Wednesday, April 15th, 2009

Speeding Up Urchin with Dojo, Part 2

Category: Dojo, Google

Last year, we covered Pete Higgin’s blog talking about how to load Google Analytics in a more responsive manner. Google may not have improved the situation since then (really?), but the Dojo folks have packaged up Pete’s script into the recently released Dojo 1.3 and Alex Russell recently posted a great summary of issues with Google Analytics and an example of the new code:

[Google Analytics] but it tends to load slowly. There are several reasons for this:

  • Another DNS lookup to resolve This DNS entry is likely to be “warm” given how frequently ga.js is used on the web, but as Jim Roskind explained on the Chromium blog, it’s the outliers that kill you.
  • It’s kinda big. At 9K on the wire (22K unzipped), ga.js is kinda chunky for what it does most of the time, namely tracking a single page load.
  • The default instructions are bone-headed. They direct you to do a document.write() which is a blocking, synchronous operation WRT page loading. This is tres dumb. Reasonable people should just include ga.js with a <script> tag, but nearly nobody does. Turns out that sane defaults still matter.
  • Load times seem totally random. As with DNS lookup, ga.js’s latency varies wildly. This isn’t backed up by anything empirical, but many pages feel blocked by ga.js for a near eternity.

The code is now simplified into this:

  1. <script type="text/javascript"
  2.  src="">
  3. </script>
  4. <script type="text/javascript">
  5.   dojo.addOnLoad(function(){
  6.     setTimeout(function(){
  7.       dojo.require("")
  8.       dojo.addOnLoad(function(){
  9.         var tracker = new{
  10.           acct: "UA-XXXXXX-X" // your tracking # here
  11.         })
  12.       })
  13.     }, 100)
  14.   })
  15. </script>

Check out Alex’s blog entry for more details.

Posted by Ben Galbraith at 8:30 am

4.2 rating from 33 votes


Comments feed TrackBack URI

looks like you’re escaping your HTML entities twice…

Comment by lunatic77 — April 15, 2009

Whoopsie-daisies. Fixed. Thx

Comment by Ben Galbraith — April 15, 2009

The irony. Won’t this just move the DNS lookup wait to “”, and isn’t the script to load “dojo.xd.js” also synchronous, and isn’t “dojo.xd.js” larger than “ga.js” (30k vs. 22k)? At least put a “defer” in the dojo script call to make it asynchronous in IE.

You might as well just put “ga.js” at the very bottom of the page so it gets loaded last without blocking earlier content.

Comment by Jordan1 — April 15, 2009

at the bottom of the page it will still block the onLoad event, which is bad.
I don’t like this solution either. In my mootools world, I just need to mix the Asset class inline in the main js file that weighs in 1.37kb YUI compressed (around 900 bytes in GZIP), and then just do a deferred load of gs.js in the window load event.
jQuery can also do this using getScript, I certainly don’t know why people create plugins for something so trivial it needs 3 lines of code.

Comment by gonchuki — April 15, 2009

To me this seems to be pointless considering google is dumping Urchin in just a few months

Comment by jaimz — April 15, 2009

By waiting for window.load, don’t you risk missing a page view in GA for visitors who leave the page before everything loads?

For instance, if you have a page with 200kb of images that viewers tend to click off of quickly, isn’t it entirely possible for stats to be skewed compared against pages with less resources to load?

Comment by marcolepsy — April 15, 2009

why would you care about that user that left your site? analytics is not about getting an artificially inflated number of visitors, it is about tracking how many people really navigated your site, while collecting useful data about them.
A user that left your site before it finished loading, is a user that’s not generating any benefit to you. It’s like he never existed at all.

Comment by gonchuki — April 15, 2009

I hope this is just a case where your irony has gone over my head but do you really not see the value in knowing your bounce rate? If your users are leaving your site before it finishes loading, you might want to know that so you can do something about it…

Comment by okonomiyaki3000 — April 15, 2009

What if, for whatever reason, the site remained not fully loaded for the entire duration of a user’s visit?

Comment by Darkimmortal — April 15, 2009


As the post says, I was already pulling in dojo.js for something else. This is about additive lag. If you’re not using dojo.js, I don’t recommend you start just to get this snippet working. If, OTOH, you want to do some DOM stuff besides, it’s a good solution.

There are both other horses *and* other courses ;-)


Comment by slightlyoff — April 15, 2009


Not sure about you, but I’d be hoping that would show up in my logs as anomaly and therefore that my visitor logs could serve as some sort of signal that there’s a bigger problem.


Comment by slightlyoff — April 15, 2009

can it count as bounce rate if the user didn’t even see what you had to offer? I only care about people that seen my content and then gone away.
It’s like a real life store, you don’t count passers-by as bounce rate, only the ones that did enter the store and left with their empty hands.
btw, you can get an approximate measure of “passers-by” by analyzing your apache logs (or whatever server you use) and counting against your analytics. It’s not ideal, as it is also not ideal to stand in the front of your store to do the same thing with people passing by.

Comment by gonchuki — April 15, 2009

Multiple pages of my site have large images, along with links visitors might click on before the page fully loads. Bounces aside, if someone shows up at page C from page A by way of page B, I’d like to know it. I’d wouldn’t want to worry about whether slow connections are skewing my stats.

Comment by marcolepsy — April 15, 2009

Leave a comment

You must be logged in to post a comment.