I needed asynchronous javascript support for my sites which, unfortunately, are still running Drupal 5. This patch expands legacy/ga.js selector to legacy/traditional/async. I also updated the .js file to track links using the async API when needed.

Don't know what the policy is for adding major features to a Drupal 5.x release, but hopefully this patch can at least help someone else stuck in a similar situation.

CommentFileSizeAuthor
#9 googleanalytics_d5_async.patch16.94 KBeli
ga_drupal5_async.patch16.97 KBeli

Comments

hass’s picture

hass commented
Priority: Normal » Minor

The original idea was - no further development for 5.x as there is no "real" need. D7 comes out soon and d.o runs D7 as know... since yesterday. I have not written D5 code since.. I guess ~2 years? I do not like to commit your code to the stable 1.x branch, but if you are willing to write an async only version like 6.x-3.x we can commit this as unsupported to 5.x-2.x or 3.x.

Not sure why you think you need the async version... ga.js works great and I guess google will not discontinue the previous tracking API within the time ga 5.x is supported...

Let me know, please.

eli’s picture

eli commented

Yup, that seems totally fair. I can spin it off as an async only version. I'll take another look at 6.x-3.x, maybe it's easier to just do a straight backport of that than move forward with what I have.

The big reason for switching to async is it improves our page view numbers! Since it loads GA much sooner, there is less of a chance of someone clicking a link or otherwise leaving the page before they can be counted. My pages might be a bit extreme (they're "heavy" -- multiple external JS files are called and lots of images), but it used to take about 2 seconds to actually count an impression with the ga.js at the bottom of the page. With the new async code in , it takes about 600ms.

I believe you need to be on the async code to use some of the new Google API features like the new Event Tracking stuff.

And finally, I suspect that at least in some browsers it will make the page load faster since the browser knows it doesn't have to wait for ga.js in order to render the rest of the page.

hass’s picture

hass commented

Ah, no. Event tracking works with ga.js. I'm sure if you compress JS i'm pretty sure you will see faster loading than in async code. I really guess you have other technical server issues...

eli’s picture

eli commented

hass-

Drupal's html filter ate the tags in my above comment, so apologies if that was confusing.

Compression has nothing to do with it. In fact, the traditional and async snippet load exactly the same ga.js file off exactly the same server! But since script tags are executed by the browser in the order they are written in the HTML, the big difference is *where* that call to ga.js is located.

For example, our pages have a bunch of Javascript littered throughout the pages: calls to our ad server, a facebook widget, a twitter widget, etc. With a traditional call to ga.js at the bottom of the page, all this inline javascript has to execute *before* the browser calls ga.js and logs an impression. If you navigate away before the page completely finishes loading, you probably weren't counted.

In Google's words:

One of the main advantages of the asynchronous snippet is that you can position it at the top of the HTML document. This increases the likelihood that the tracking beacon will be sent before the user leaves the page. We've determined that on most pages, the optimal location for the asynchronous snippet is at the bottom of the <head> section, just before the closing </head> tag.

Make sense?

Eli

hass’s picture

hass commented

You can put the ga.js file link in the head to fetch the file earlier and you can cache it local + aggregate it, but the fireing call to google MUST stay in the bottom of html. There are technical reasons we cannot solve in D5 nor D6, but D7. So you end up in the call is executed as latest call. See the details at #921308: Document that module using asynchronous javascript but not able to correctly load code in header. Please don't tell me again google suggest to add async code to head...

eli’s picture

eli commented

Hi hass-

Thanks for being patient with me, but I think I'm now more confused then when I started. Google says it's best to put all the code in the <head>. (I meant to link to http://code.google.com/apis/analytics/docs/tracking/asyncTracking.html above). But you say that's not possible?

I read the issue you linked to. As far as I can tell the problem is that you can't add JS to the header from a hook_footer, right? OK, but then why not just add the code to the header in a hook_menu instead? That's how older versions work and that's basically what my patch above does, and it seems to work perfectly. Is there some disadvantage to doing this that I'm missing?

Eli

hass’s picture

hass commented

It doesn't matter what google says... it only matters - when are you able to collect all data you need to generate the tracking code.

You cannot add the async code to hook_menu(). At this level you do not have all data that you need. Examples are tracking of 403 and 404. You cannot detect the status codes at this level. I cannot remember 100% for sure if it was possible in D5 to call drupal_add_js() in footer with scope header, but I guess this is not possible or I would have done this in past...

hass’s picture

hass commented
Status: Active » Closed (won't fix)

No progress since 2 months. Feel free to attach and updated patch.

Otherwise we leave this closed and on 5. Jan 2011 (when D7 will be released) the D5 versions become officially unsupported per Drupals support Matrix.

eli’s picture

eli commented
StatusFileSize
new googleanalytics_d5_async.patch16.94 KB

Sorry for the delay. I guess D5 is officially unsupported, but perhaps this patch will still help someone. Anecdotally, it made a noticeable improvement to the number of reported page views for us. We've been using it in production for several months now with no problems.