Speed Up Google Analytics, use local ga.js

FREE THOUGHT · FREE SOFTWARE · FREE WORLD

Speed Up Google Analytics, use local ga.js

Google Analytics ga.js SpeedLast 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

«
»

Leave your own comment

Reader Comments

  1. A Guide to Google Analytics and Useful Tools « Smashing Magazine ~

    [...] Speed Up Google Analytics “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.” [...]

  2. Arjan ~

    This won’t speed up things. Most people will have Google’s ga.js in their cache from previous visits to other sites. Your server cannot beat the cache (and probably cannot beat Google’s servers either).

  3. AskApache ~

    @ Rafał

    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
  4. Rafał Szymański ~

    Hi,
    Very interesting article. I’m not sure that is everything OK because in my opinion you have to also do 2 things:

    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ł

  5. ibme ~

    We were running into a problem where for some reason the google script code for correctly identifying http vs. https wasn’t working properly. This caused an error to generate in the server logs where it was looking for the ga.js file locally. I wasn’t able to pin point the problem with the gahost code and since it was happening only 2 to 5% of the time, I was looking for another method.

    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!

  6. Barry Hunter ~

    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.

  7. AskApache ~

    @ 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-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.

  8. Barry Hunter ~

    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 :)

Go for it!


It's very simple - you read the protocol and write the code. -Bill Joy

HTML | DCMI | GRDDL | XOXO | XDMP | XFN | DOM | XML | XHTML 1.1 Strict | CSS 2.1 | W3C

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License, just credit with a link.
This site is not supported or endorsed by The Apache Software Foundation (ASF). All software and documentation produced by The ASF is licensed. "Apache" is a trademark of The ASF. NCSA HTTPd.
UNIX ® is a registered Trademark of The Open Group. POSIX ® is a registered Trademark of The IEEE.

Site Map | Contact Webmaster | Glossary | License and Disclaimer | Terms of Service

↑ TOP
Main