4 ms·

Speeding up Google Analytics

25 points by mikexstudios 17y ago

enomar 17y ago
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.
- stanleydrew 17y ago
  With respect to (C), can you describe some other good DOM-readiness detection methods?
  - enomar 17y ago
    http://dev.jquery.com/browser/trunk/jquery/src/event.js#L802 http://dev.jquery.com/browser/trunk/jquery/src/event.js#L802
  - superjared 17y ago
    MooTools' DomReady is a great example: http://mootools.net/docs/core/Utilities/DomReady http://mootools.net/docs/core/Utilities/DomReady
  - daleharvey 17y ago
    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.
    - 124816 17y ago
      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.
      - enomar 17y ago
        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.
    - enomar 17y ago
      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.
cryptnoob 17y ago
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.
- 124816 17y ago
  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.)
  - enomar 17y ago
    https://bugzilla.mozilla.org/show_bug.cgi?id=487638 https://bugzilla.mozilla.org/show_bug.cgi?id=487638
- enomar 17y ago
  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.

25 points by mikexstudios 17y ago

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.

stanleydrew 17y ago
With respect to (C), can you describe some other good DOM-readiness detection methods?
- enomar 17y ago
  http://dev.jquery.com/browser/trunk/jquery/src/event.js#L802 http://dev.jquery.com/browser/trunk/jquery/src/event.js#L802
- superjared 17y ago
  MooTools' DomReady is a great example: http://mootools.net/docs/core/Utilities/DomReady http://mootools.net/docs/core/Utilities/DomReady
- daleharvey 17y ago
  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.
  - 124816 17y ago
    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.
    - enomar 17y ago
      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.
  - enomar 17y ago
    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.

cryptnoob 17y ago

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.

124816 17y ago
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.)
- enomar 17y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=487638 https://bugzilla.mozilla.org/show_bug.cgi?id=487638
enomar 17y ago
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.