| 3:40 pm on Oct 15, 2008 (gmt 0)|
It will cause a small performance issue.
The trouble is that the JS file is loaded from Google servers... sometimes they are fast but from time to time they are slow.
You are right that if you put the call to the JS before the </body> that your content will load before the Google code.
Your developers are right to warn you but it isn't enough reason to not have the tracking code if you think you will benefit from it.
Unless the shopping cart is poorly written it shouldn't interfere.
| 6:08 pm on Oct 15, 2008 (gmt 0)|
Where are the developers getting their information (if there is more to their opinion than information)? Instead of asking for proof that it won't affect anything, they should have some indication that it will. And that it could be significant.
The developers should be able to put this to the test with perfmon or a client-side test tool.
Do the developers have any idea of what degree of slowdown would be unacceptable i.e. change visitors' immediate or long-term behavior?
What do the developers suggest doing instead? No analytics at all? How does management feel about that?
Tell them to step up!
| 6:30 pm on Oct 15, 2008 (gmt 0)|
Plan your page layouts so the analytics will be the very last thing to load. You might be able to measure a difference in total load time, but few users would notice any difference.
I like to enclose my analytics snippets within a DIV that specifies height and width (usually 1x1), as well as putting it very last on the page.
| 6:31 pm on Oct 21, 2008 (gmt 0)|
See also this thread [webmasterworld.com] from three weeks previous.
| 6:37 pm on Oct 21, 2008 (gmt 0)|
When Google first launched their analytics product, I believe they recommended outing the code within the <head> section of the HTML. And they also had a variety of problems with server speed. This caused entire pages not to load on some sites (since browsers might wait for a timeout before loading the rest of the content).
Google seem to have addressed the server speed problem, and of course, you can now put the code as low in the HTML as possible (i.e. just before </body>) so the worst downside if Google's servers are slow or unavailable is the browser might indicate that the page has not finished loading. The content should still display fine.
Of course, you should try to avoid ever relying on third party code for key elements of a page to run successfully.
| 7:21 pm on Oct 21, 2008 (gmt 0)|
|if Google's servers are slow or unavailable is the browser might indicate that the page has not finished loading |
Through several implementations, this is about the only performance issue I've run into.
The result was that the "Page Loading" icon would continue to run until the GA script had finished. Sometimes this was a surprisingly long time (upwards of 60 seconds).
Moral --> be careful how you use the body tag when implementing 3rd party scripts from within the body.
| 7:32 pm on Oct 21, 2008 (gmt 0)|
|heavy reluctance from our developers to put Google Analytics tags on our ecommerce site |
Incidentally, they are likely wrong that this will have any impact, but I'm usually much more happy with a cautious developer than one who will slap any old code anywhere without any questions ;)
| 8:53 am on Oct 22, 2008 (gmt 0)|
Having spoken with the developers yesterday it turns out that the issue is as follows;
Our site currently has a number of tags on it including Atlas and Doubleclick (for affiliates and banners) Surfaid (our current analytics. Recently they inserted tags for InQ (similar to Liveperson) and a conflict occurred with the Atlas tags which caused pages not to load even though the tags were at the bottom of the page.
Can anyone suggest a way that we can test or analyse the JS for potential conflicts before implementation?