views:

427

answers:

3

From an old answer I have recently learned that Google Analytics, besides the traditional tracking code, offers so-called "asynchronous tracking". From the documentation, it seems like asynchronous tracking is to be preferred over the traditional tracking:

Unlike a traditional installation, asynchronous tracking optimizes how browsers load ga.js so its impact on user experience is minimized. It also allows you to put your Analytics snippet higher in the page without delaying subsequent content from rendering.

The documentation mentions no drawbacks from using asynchronous tracking, which makes me wonder why this is not the default tracking method. Are there any pitfalls around asynchronous tracking that one should be aware of, or should I go ahead and make the switch on all installations?

+2  A: 

It's a very simple thing. The script tag that calls GA is created via DOM. ...

see this: http://stackoverflow.com/questions/895971/asyncasync-attribute-of-a-script-tag-in-html-what-does-it-mean

If your pages render correctly with GA set to async -- most likely they will -- then you are good to go. They will render slightly faster.

Dercsár
Whats with the "most likely"? Are there situations where trouble is expected?
Jørn Schou-Rode
Changing the scripts to async may change what you see when the page is rendered (displayed) in the browser. Try it in the browsers you used to test your pages. When rendering is finished, you should see no change.
Dercsár
+1  A: 

Async tracking was only released 2 months ago. They're just beta testing it before they unleash it on the entire web. They only trouble I've heard people have is with something Google calls out on its installation page:

We've determined that on most pages, the optimal location for the asynchronous snippet is at the top of the <body> section. While it is customary to place JavaScript code in the <head> section, placing the asynchronous snippet there may trigger a parsing bug in Internet Explorer 6 and 7 on some pages. The easiest solution to this problem is to place it at the top of the section.

Brian
@doug: I don't know why I can't comment on your answer, but you're incorrect. The async snippet uses 2 methods to make itself asynchronous. One is the HTML5 async attribute and the other is the "Script DOM Element" approach to dynamically inserting scripts. The HTML5 method may only (currently) work in Firefox, but the SDE method works in IE, Safari and Chrome.
Brian
@Brian: Very interesting! I didn't know about the SDE approach to ayns script loading.
Jørn Schou-Rode
More technical info about GA async: http://ajaxian.com/archives/google-analytics-unblocks-the-web-w-async-support
Jørn Schou-Rode
The Ajaxian (and many other) articles on this subject are out of date. For the most recent info, see the GA codesite:http://code.google.com/apis/analytics/docs/tracking/asyncTracking.html
Brian
+1  A: 

In a strict sense, swapping out ordinary GA code for the asynchronous code should not cause any harm--according to the W3C spec, if a browser does not support the 'async' tag, then it just ignores it.

In practice though, i think it will--at least until the relevant HTML5 feature responsible for the GA async code's behavior, is implemented across substantially all Web Browsers.

As pointed out in the Question above, the intention behind the asynchronous code is that the Site owner's will place it higher in the page (vs. the bottom of the page, in accord with the current practice). Again, the idea here is that doing so will provide more accurate counts because it substantially reduces the the number of cases in which the user closes the browser before the js is loaded.

AS of the end of 2009, the only browser that supports this particular feature of HTML5 (i.e., 'script' tag's 'async' attribute) is Firefox 3.6.

Hence if you place all of your GA js code near the top of the page then only when the page is rendered in FireFox 3.6, can you expect the page to load faster that code w/out the 'async' attribute. For all other browsers, the async code will slow down the page because purely because of it's new (higher) position on the Site's pages.

doug
See comment at Brian's answer.
Jørn Schou-Rode