If you did that then Google Analytics would not work! Google uses the __utm.gif file as a method to pass various stats on to the Google Analytics engine. If you request the __utm.gif file on your own server, then Google Analytics will not work! Check out the Host: header field from this WireShark dump, this shows that hosting the ga.js on your server works but only because its still calling google-analytics.com/__utm.gif.

GET /__utm.gif?&utmp=/linux-unix/ga-urchin-speed.html&utmac=UA-732153-7
Host: www.google-analytics.com
Referer: http://www.askapache.com/linux-unix/ga-urchin-speed.html

1. Copy _umt.gif from Google to your server
2. edit ga.js to add new url for _umt.gif. Without this changes just copied ga.js will not work correctly on your local server.

In original ga.js it’s look that:
lc:"http://www.google-analytics.com/__utm.gif",mc:"https://ssl.google-analytics.com/__utm.gif"
in your local file should look that:
lc:"http://www.yourdomain.com/__utm.gif",mc:"https://yourdomain.com/__utm.gif"

So, challenging is to make script to made this changes in every updated ga.js

Best regards
Rafał

Your solution of downloading and hosting the ga.js file locally is an elegant solution to our particular problem. This way, the ga.js is always local and we don’t have to use the https identifying code.

Hopefully our error / issue will go away.

Thanks!

> The google-analytics.com servers are configured to return a random Last-Modified date EVERY single time a browser requests http://www.google-analytics.com/ga.js

It validates for me here tho (tried it three times)
http://www.ircache.net/cgi-bin/cacheability.py

Its probably just that different datacenters have slightly different versions of the file, so sometimes you hit one, sometimes another? (another common problem with etags)
- so if that is the case then it is rather a shot in the foot – both for Google, and visitors to sites with GA.

They do also have a ‘max-age’, so most of the time the browser wont even bother with the conditional get.

> your browser has to follow up the 304 If-Modified-Since request with a FULL GET request,
I thought it was a ‘conditional get’, ‘Ive got this file, if it matches this date dont bother sending it’, so if the dates match server returns 304, otherwise 200 and the new content.

> Also don’t forget about HTTP/1.1 ability to use persistant connections.
Ah of course! Although I know have tended to disable it on high traffic sites, lots of clients maintaining connections, eats up apache threads, siting around doing nothing. Having lots of threads in the cache ready means minimum startup time on each connection, and the overall server performance is better – of course there may be some other apache setting to help with this – or for small sites is perfectly good.

Your logic is correct but unfortunately google throws a wrench into it. For unknown reasons, at least I can’t figure it out, The google-analytics.com servers are configured to return a random Last-Modified date EVERY single time a browser requests http://www.google-analytics.com/ga.js which of course means that ga.js CANNOT be cached by any browser. Therefore, every time a browser loads a page that includes the ga.js file from google, it has to make a 304 If-Modified-Since request to see if the file has changed.

Because google returns a different Last-Modified date EVERY single time, your browser has to follow up the 304 If-Modified-Since request with a FULL GET request, meaning it has to re-download the entire file, for every single page load.

This is wayyyyyyyyyyyyyyyyyyyy slower than hosting it on your own server, for obvious reasons.

Of course, hosting it on your own server wouldn’t be much faster UNLESS you implement server-side caching, which I take full advantage of on AskApache.com, so, my site loads much faster in regards to ga.js.

Also don’t forget about HTTP/1.1 ability to use persistant connections. Basically this means that when a client/browser requests http://www.askapache.com/linux-unix/ga-urchin-speed.html, it caches the reverse DNS for askapache.com, and opens a persistant connection to my server. So, followup requests for additional resources like images, css files, js files, etc.. all happen using the same connection, which equates to speed.

So If a client already has a persistant connection to my server, and If I have solid caching set up on my server, and If I want my site to be faster, I will host ga.js locally. When google changes their caching policy, then of course it will be faster to NOT host ga.js locally, and your suggestions will be absolutely correct.

On a remote server in the UK (so no local user to prime the DNS), from Google takes, 0.7s, but from yours 1.7s then once the DNS has been primed, 0.4s from Google and then 0.8s from your z. server.

Also this negates caching in some cases as its quite possible a user has the file loaded from visiting a another website, upon visiting your site they have to download it again.

Save yourself the bother of maintaining it, and the bandwidth and let Google host it, I say :)