Move tracking code to top?

We could add the JS file dirty to the $head variable that is not available in all themes... or we better wait for patch http://drupal.org/node/91250 going to be committed.

You can go there and test... so we could have a chance to get this into D6 or it must wait for D7 or later.

Or you could just do it like mentioned in the thread you linked...

drupal_add_js('</script><script type="text/javascript" src="http://www.google-analytics.com/urchin.js">', 'inline');
drupal_add_js('_uacct = "UA-XXXXXXX-1";urchinTracker();', 'inline');

Works in D5.

Ok here is what I have done. In the module replace this line:

$script = '<script type="text/javascript" src="'. $source ."\"></script>\n";

with this:

drupal_add_js('</script><script type="text/javascript" src="'. $source .'">', 'inline');

This adds the google analytics javascript file to the head of the page, rather than the footer.
The user account setting and initial urchinTracker() call will still be in the page footer, as they should.

But it will mean that you can tag outbound link click events with urchinTracker without getting function undefined errors.

Tested and working in Drupal 5.

Don't mark your own code as RTBC. Aside - only a patch could be RTBC.

boo hoo... cry me a river. Just trying to help.
Thats the last time i solve a problem for you.

Anyway I hope it helps anyone else out there who has this same problem that has been ignored for months.

The linked cases do not depend on moving the JS file on top... i'm using outbound links tracking myself and it works, well. The JS functions behind are only executed after a page is total load and therefor all function in urchin are available. Adding outbound links tracking automatically to every/some outbound link - is for sure not a trivial task.

Aside, help is welcome, but patches are required for ease of use and review process. Please do not try to circumvent review processes. This could cause a crippled or broken module what is this review process for and we all do not want. Check out the handbooks, i'm sure there are more argues about this :-).

here is the patch - hass is right. took me less time to do the patch then it took to post this message. not tested, as I dont need this.

Sorry, this patch is a dirty hack and not a clean and good solution.

drupal_add_js('</script><script type="text/javascript" src="'. $source .'">', 'inline');

This cause an senseless open and close script tag that looks invalid, too and this is nothing we should do. If we move this to the top without the core patch for external JS, we could place it in $head with drupal_set_html_head(), but a visible page loading delay will come together with this change and i'm not sure if we all like this much.

Can someone say for sure that every available theme have $head placeholder? $footer should be much more save...

I agree with the page load delay. This is why Google recommend placing it in the bottom of the page, not the top. I would assume all themes have $head, but you know what they say about assumptions. I am happy to have this sitting where it is in the original code. I suggest people who need this really badly provide a patch that will allow the user to choose placing this in $head or $footer

Well, that could be a much better idea to give admins a choice about top or bottom and do this in a clean way.

Yes but by placing the script at the bottom, you miss clicks when someone clicks a link before the page is fully loaded.

The linked cases do not depend on moving the JS file on top... i'm using outbound links tracking myself and it works, well. The JS functions behind are only executed after a page is total load and therefor all function in urchin are available.

If you have outbound link tracking going, you will get a script error if they click a link before the page has fully loaded the script which is the last thing on the page.

If your page isn't fully loaded when somebody can click, you should solve your page loading performance instead of moving the JS to the top. Putting JS at the top of the page will only slow things down further for the user.

Firstly Wim, I appreciate your opinion but please don't use a straw man argument to make your point.

No-one in this thread has mentioned anything about performance issues until you just did. The issues raised are that the current solution does not protect from script errors if a user clicks an outbound link before the script has loaded, plus any inline custom outbound link tracking generates a script error if the script is not included before a reference is made to urchinTracker (the outbound tracking included with this module is not sufficient for my needs, as I want to track scripts internal to my domain that redirect to external sites).

As to perceived "slowdowns" by placing a script in the head element (ignoring that 99% of other scripts are placed in the head where they should be), I disagree because:

1. The script is cached the first time it is loaded.

2. Most browsers load scripts from different domains in a separate http "thread", while playing nice with http specs they only initiate 2(?) threads for any one domain, including the one you are browsing. So it is loading the script in parallel from google's domain at the same time as content from the domain being browsed.

In fact that just illustrates that the option included by this module to host the google script on your own domain may in fact cause the page to load slower instead of faster as intended, because it must wait for everything else on the page from your domain to finish first. No to mention you lose the benefit of any edge server / intermediate proxy caching.

Either way, the difference is likely to be measurable in a tiny number of milliseconds.

Anyway, I've already linked to 3 other threads started by independent people who all want this OPTION in post #6. No-one is asking for the module to be changed to always do this. If you don't like the option, then don't worry about it - it doesn't apply to you and you'll never switch it on, so you can sleep easy at night.

Firstly Wim, I appreciate your opinion but please don't use a straw man argument to make your point.

Sorry, I didn't realize that.

No-one in this thread has mentioned anything about performance issues until you just did. The issues raised are that the current solution does not protect from script errors if a user clicks an outbound link before the script has loaded, plus any inline custom outbound link tracking generates a script error if the script is not included before a reference is made to urchinTracker (the outbound tracking included with this module is not sufficient for my needs, as I want to track scripts internal to my domain that redirect to external sites).

The solution is really simple: set a class on the anchors with outbound links, and let a .js file bind that urchinTracker function to the click event. Inline
JS is discouraged anyway: all JS should go through drupal_add_js().

As to perceived "slowdowns" by placing a script in the head element (ignoring that 99% of other scripts are placed in the head where they should be), I disagree because:

1. The script is cached the first time it is loaded.

The script may be cached, but only for a week (604800 seconds). And the first page load is very often *critical*!
E.g. you're visiting the site of a person you want to hire. The header of the page is loaded very quickly, but the rest of the page is still loading. Or even worse: there's a blank page for a long time, before you get to see any content. I'm sure you've seen this happen yourself too. The reason? When a .js file is loading, it delays the rendering of *everything below it in the HTML*.
That's detrimental to performance, and also for the user experience.

2. Most browsers load scripts from different domains in a separate http "thread", while playing nice with http specs they only initiate 2(?) threads for any one domain, including the one you are browsing. So it is loading the script in parallel from google's domain at the same time as content from the domain being browsed.

In fact that just illustrates that the option included by this module to host the google script on your own domain may in fact cause the page to load slower instead of faster as intended, because it must wait for everything else on the page from your domain to finish first. No to mention you lose the benefit of any edge server / intermediate proxy caching.

If you're using JS aggregation – and you should, that statement no longer applies.

Either way, the difference is likely to be measurable in a tiny number of milliseconds.

Not true. For example, if I ping google.com (I live in Belgium), it takes 130 ms. Multiply that a couple of times (once per file request), and that quickly becomes a pretty large number.
Also, .js files can be pretty large these days (easily >100 KB per page, Digg for example is 140 KB), which may take some time. It's definitely not a matter of milliseconds! Actually it only *could* be a matter of milliseconds when it's hosted geographically close to the user *and* when JS aggregation is enabled.

Anyway, I've already linked to 3 other threads started by independent people who all want this OPTION in post #6. No-one is asking for the module to be changed to always do this. If you don't like the option, then don't worry about it - it doesn't apply to you and you'll never switch it on, so you can sleep easy at night.

I understand that :) I'm only trying to warn that you're not fixing the root of the problem: inline JS. You're simply working around it.

I'm sorry I didn't state that clearer, but that really was my point: you're not fixing the root of the problem, but the consequences.

The solution is really simple: set a class on the anchors with outbound links, and let a .js file bind that urchinTracker function to the click event.

Yes great, I know you can do this - this is what the current solution for links to other domains does, but once again this will not track clicks made before the function is bound, which has to wait for the script to be downloaded and parsed first, no matter if it is at the top or bottom of the page source. You see, that's why "the difference is likely to be a matter of milliseconds."

If you're using JS aggregation

Well actually no I'm not because the results were disastrous when I tried. Script errors galore. Maybe some modules don't play nicely together?

And besides I would rather users only have to download a single small script that has changed, rather than all the scripts on my site which have been put together in one larger script and cached, just because one of them changed one line. Once again, "performance" considerations are not as straight-forward as you may like to believe, and what works for one site does not always work for every site.

Also, .js files can be pretty large these days (easily >100 KB per page, Digg for example is 140 KB)

Google's tracking script is 26kb uncompressed.

And for the people saying leave it at the bottom because "this is what google recommends", I'll quote Google themselves on that:

Important: if your pages include a call to _trackPageview, _setAllowLinker _trackTrans(), your Analytics tracking code must be placed in your HTML code above any of these calls. In these cases the tracking code can be placed anywhere between the opening body tag and the JavaScript call.

http://www.google.com/support/googleanalytics/bin/answer.py?answer=55527...

Anyway sorry this thread has gotten a little derailed. I think I've made it very clear why it would be nice for some people to have this option, so I won't bother anyone any more with this.

Please try this patch.

It does some major changes to GA and allows us to easy switch the scope 'footer' to 'header'. Make sure to test aggregated JS, too.

Rerolled patch attached.

subscribing

Fixed for next D5 release.