Speeding up Google Analytics | Hacker News Reader

Speeding up Google Analytics

neil.fraser.name

25 pointsmikexstudios12 comments

The author is ignoring that:

A) Most sites do have content with which async GA can load in parallel.

B) Where you put the GA snippet is a trade-off. Putting after window.onload will decrease the time it takes to get to window.onload, but it will also lessen the accuracy of your data; especially your bounce rate.

C) If you're worried about delaying user visible functionality that is tied to window.onload, you shouldn't be tying that functionality to window.onload in the first place. There are better ways to detect when the DOM is ready to use.

With respect to (C), can you describe some other good DOM-readiness detection methods?

MooTools' DomReady is a great example: http://mootools.net/docs/core/Utilities/DomReady

http://dev.jquery.com/browser/trunk/jquery/src/event.js#L802

put the script at the bottom of the page

I never understood why onload and all the frameworks implementing domloaded exist, script tags generally should go at the end anyway, and there is no problems with dom availability.

This is fine, if you're OK with missing bounces. If the page takes a long time to load, or hangs, then it's likely the user will close the window before the script runs.

I don't think he was necessarily suggesting putting GA at the bottom of the page. I read this as, "put the DOM ready detection" at the end of the page.

When you're writing a third party script you don't have control over where in the page someone will put it. Having code to detect DOM ready is useful in these cases.

I use my own server side analytics code. The reason I do, is that, no matter how much people pump Google Analytics, I'm afraid of it. I've been to too many sites that were completely hung, and in the status bar, my browser is saying "waiting for www.google-analytics.com".

I usually hit refresh and it generally works, but how many people don't? This isn't something that's happened to me once or twice. It happens often enough that I'm consciously avoiding ga. I don't need to cause more people to bounce for no reason.

Several browsers, including many versions of Firefox, had a bug relating to the status bar. The "waiting for ..." would only update after the first byte had been received from the next file. Thus, a slow resource would leave the status bar blaming www.google-analytics.com.

The bug has since been fixed in Firefox -- I don't have the url handy though.

IMO this is the main benefit of the async snippet -- random server problems won't lead inaccurate metrics.

(This is most visible with adwords campaigns -- you can see the number of clicks you paid for, but the number of visits they lead to is less. Typically due to a combination of high bounce rate plus slow loading pages.)

https://bugzilla.mozilla.org/show_bug.cgi?id=487638

Much of what you're referring to is historical. Google fixed their serving infrastructure in early 2009 to be faster and much more reliable. Also as someone else posted, FF was incorrectly blaming the last thing on page for being slow, which was ga.js. That's been fixed in 3.6. Additionally, they've released asynchronous tracking, which you should definitely try.

Reply on news.ycombinator.com