Last year I wrote about hosting Google Analytics urchin.js file on your own server, to speed up the loading of your site. Well, google has migrated to a new analytics javascript, ga.js. You can read the urchin.js to ga.js migration guide if you want. They also wrote about the changes on the Google Analytics Blog. And if you want to learn about advanced features of ga.js check out this Google Analytics Documentation.
XHTML for hosting ga.js locally
If you use a relative link like below, you don’t need the https detection part of the script.
Also note that the -151 is from my advanced mod_rewrite Fix for Caching Updated Files. So you won’t need that unless you implement that technique.
<script src="/j/ga-151.js" type="text/javascript"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-732153-7");
pageTracker._initData();pageTracker._trackPageview();
</script>
Shell Script to Update ga.js
Here is an updated shell script that fetches the latest ga.js file from google and places it in the folder of your site.
#!/bin/sh
# TMP DIRECTORY
MYTMP=/tmp/
# SAVE ga.js HERE
INSTALL_IN=/home/user/askapache.com/z/j/
# RESOURCE URLS
GOOGLE_GA_URL=http://www.google-analytics.com/ga.js
# USER-AGENT
UA="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
# CD TO TMP DIRECTORY
cd $MYTMP
# DOWNLOAD THE FILE
curl --header "Pragma:" -f -s -A "${UA}" -m 1800 --retry 15 --retry-delay 15 --max-redirs 8 -O $GOOGLE_GA_URL
# GIVE FILE CORRECT PERMISSIONS
chmod 644 $MYTMP/ga.js
# COPY FILE TO SITE DIRECTORY
cp -r $MYTMP/ga.js $INSTALL_IN
# RETURN TO OLDPWD
cd $OLDPWD
exit 0;
Updating ga.js with Crontab
Just add this to your crontab by typing crontab -e where google-analytics-update.sh is the location of your shell script.
@daily /home/user/scripts/google-analytics-update.sh >/dev/null 2>&1
More Speed Tips
- mod_rewrite Fix for Caching Updated Files
- Speed up your site with Caching and cache-control
- Top methods for Faster, Speedier web sites
Related Articles
- Speed Up Google Analytics with urchin.js
- Use php.ini to replace html with anything
- Advanced Google Analytics 404 Error Page
- mod_rewrite Fix for Caching Updated Files
- Security Enhancing with htaccess
- Auto-Login to Google Analytics to impress Clients
- Fetch Feed Subscribers from Google Reader with CURL
- Replacing ‘%23′ with ‘#’ in incoming links
01.30.08 at 8:55 am
I’ve seen things like this suggested before (non Analytics), but this is assuming you have global connectivity better than Google. On the whole your server might be closer to you, but its quite possible Google have a datacenter closer to many of your visitors.
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 :)
02.01.08 at 11:19 am
@ Barry~
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-Modifieddate EVERY single time a browser requestshttp://www.google-analytics.com/ga.jswhich 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.
02.01.08 at 11:47 am
Thanks for the responce,
> 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.