Tracking Code and Click Response Delays

Sometime last year I tried out Clicky, a web analytics service offering real-time¹ traffic monitoring. I was really impressed with a few of the features, in particular the “Spy” feature, which provided real-time data of visitor activity at the user level. Being able to watch, in real time, a user move through a site was a novel thing (although not necessarily a useful thing). With their iPhone-friendly dashboard I could even watch activity on a site when I was out to dinner, which I thought was very cool. (My girlfriend, by the way, did NOT think this was very cool.)

All was good. Monitoring web traffic in real time on the go, it felt like the future had arrived. Surely the jetpacks and hoverboards were just around the corner.

Enter the other shoe. After a few weeks I noticed that something on my site felt sluggish. The something turned out to be clicks on external links, and the culprit turned out to be Clicky.

Clicky’s script was capturing click events on external links and imposing a 500ms delay to allow the script enough time to fire the event data back to their servers. Even though it only applied to external links, a half second delay was too much, so I tweeted the discovery and decided to jettison the script—partly because of the performance hit and partly because the free trial providing access to the Spy feature had expired.

Analytics on the rocks, ain’t no big surprise. We go on. We must go on, we can’t go on, we’ll go on.

Skip ahead to yesterday, when I was asked to add tracking code for Nielsen NetRatings to a site.  It was my first time seeing the code (I’d actually never heard of NetRatings) and I was naturally a little suspicious.  After adding the code I immediately noticed a performance problem: the response to clicking on any link, including internal links (links to pages on the same domain), was noticeably delayed.

A quick look through the code turned up this pause function:

function _rsPause(_rsMillis) {
  var _rsDate = new Date();
  var _rsCurrDate;
 
  do { 
    _rsCurrDate = new Date(); 
  } while(_rsCurrDate - _rsDate < _rsMillis);
}

The default, hard-coded value for _rsMillis was 500, as in 500 milliseconds, as in a half second, as in a really long time by web performance standards.

The important thing to note here is that unlike Clicky’s pause function, which ran only on external links, the NetRatings pause function runs on every link, meaning users are subjected to a half-second delay each time they view a new page on your site.

You may think that a 500ms delay is not that noticeable. If so, I invite you to try out this demo to witness just how noticeable it is. You can also click around on Nielsen Wire to observe the effect on a real site.

At the risk of emphasizing the obvious, I’d like to point something out. As people-who-care-about-performance we spend a lot of time and energy optimizing what happens after the moment the server receives a request. But how we get to that moment is just as important. To the user there is no difference. A half-second wait on the way out is the same as a half-second wait on the way back. It’s just time spent waiting for what they asked for.

Is there anything to be done?

Aside from choosing not to install tracking solutions that come with such a performance penalty (which is not always an option), your best option is to replace the default 500ms timeout in these scripts with something less obtrusive. 100ms is considered the threshold for what we perceive as instantaneous response (see the demo)². Both Clicky and NetRatings allow you to override the default delay in the initialization code.³ Depending on the script, 100ms may not be enough time to execute the tracking request, so you’ll have to test it out and possibly be OK with not recording every link click.

Final note: I’ve only mentioned Clicky and NetRatings but there are others that employ the same technique. Of course it’s always a good idea to take a critical look at performance effects whenever adding 3rd party Javascript to one of your sites. (Interestingly, Google Analytics seems to be able to capture outbound link clicks [via event tracking] without enforcing a timeout [at least not one that I’ve observed]. But I haven’t done thorough testing. It could very well be leaking lots of events to race conditions.)

Footnotes

• ¹ In this context, let’s assume that real-time = realish-time.
• ² See Jakob Nielsen on response times.
• ³ You can find documentation for the former here.