Analytics Expert Blog

We’ve just released a change to our tracking code that will help ensure the best user experience possible on your web site. You don’t have to change anything on your site, the changes are in the code itself that is loaded via the script element.

Previously, as soon as our tracking code loaded, it would connect to our tracking servers to log the page view. The problem here is that if things aren’t running under perfect conditions, that could interfere with the overall loading speed of your web site – especially if parts of your site depend on the onload javascript event.

We have changed the default behavior so that the initial page view is not logged until the onload event has fired. For users on very slow connections, or who browse between pages very quickly, this may result in slightly less accurate tracking. But we’ve been testing it all day on a few of our own sites (including getclicky.com) and there are no discernable differences in our numbers, so this should work well for everyone.

Of course, if you prefer the old behavior, you can change it via the new clicky_custom.delay parameter. Set it to the number of milliseconds you want the delay to be – 0 will result in no delay at all, emulating the old behavior. We recommend keeping it to the default setting however, unless it causes any problems with your tracking (and if it does, let us know).

The tracking code should be the very last thing in your HTML anyways, so changing the default to onload shouldn’t change the accuracy – it will just let your site’s onload events fire before we log data.

What about asynchronous javascript?

Google recently introduced asynchronous tracking for Google Analytics. Ultimately we’d like Clicky to have this option as well, but it’s not as easy as it sounds and we can’t make it the default behavior like we did with this change.

The main reason for that is because our tracking code has a number of javascript functions you can call after you include it in your HTML, and you’re assuming that those functions are already loaded and ready. By changing to asynchronous, we’ll have to create some kind of queue object for you to pass data to while you’re waiting for the tracking code to actually be loaded (because you’ll have no idea when that will actually happen). This will require a large rewrite of the tracking code, as well as a lot of documentation on the differences between the two methods.

The change we made today though should make a noticeable difference on your site. Logging data to our servers is generally much slower than downloading the tracking code, so this change makes a much bigger difference overall. Yes, the tracking code itself still must be downloaded before your onload event fires, but since we now use a global tracking code URL for all users, and we’re tracking almost 180,000 sites, chances are fairly good that a user arriving at your site already has our tracking code cached in their web browser. And even if they don’t, that will only affect their first page view. Every subsequent page view will benefit greatly from this change.

Of course, because they may have the old version cached already for up to 7 days, it will be 7 days before every single user on your site will be affected by this change. But in all likelihood, most of them will have it within 48 hours.