Speed up google analytics on your site!

Learned a cool way to speed up site loading time by serving an updated urchin.js file locally.

Normally the Google Analytics urchin.js file is located on the google-analytics.com server, which is clear from the Analytics Tracking Code you install on your site.

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>

Code (markup):

Official Google Position on locally hosting urchin.js

The problem is when google-analytics.com/urchin.js is requested by billions of web users all over the world at one time, it can cause your sites pages to load at a snails pace. Especially if you are using WordPress or a similar CMS.


HTTP Headers sent with urchin.js from the google-analytics server.

Cache-Control: max-age=604800, public
Content-Type: text/javascript
Last-Modified: Tue, 20 Mar 2007 22:51:38 GMT
Content-Encoding: gzip
Server: ucfe
Content-Length: 5675
Date: Fri, 23 Mar 2007 21:59:07 GMT

Code (markup):

Notice the Cache-Control header specifies that the urchin.js file should be cached for 1 week (604800 seconds) which directs your browsers cache to check the remote urchin.js file every week to see if it has been modified.


Get your local urchin.js
This method downloads an updated urchin.js file every 24 hours and saves it into your local sites directory.

So instead of this

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-333153-x";urchinTracker();
</script>

Code (markup):

its this

<script src="/z/j/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-333153-x";urchinTracker();
</script>

Code (markup):

This automated process is controlled by crontab and executes a simple shell script that retrieves the updated urchin.js file and saves it into your local server. shell script and crontab code


So what do you think? cool huh!

 

I think the gain is minimal compare to the hassle to set up a crontab, not being sure you have the script last version...

The tracker code is at the bottom of the page anyway, just before the closing body tag, the page is loaded before the script, I don't think getting the urchin.js from Google servers slow down the page loading time so much. (never measured it though)

 

Green rep coz that's a great idea. However, wouldn't the .js be cached once the user downloaded it from any site using analytics?

 

is this within Google Analytics TOS?

 

Read the original post.

 

There are 2 pretty major things that you accomplish by hosting urchin.js locally

1. You Enable persistant connections
2. You ensure that the correct 304 Not Modified header is sent back to your site visitors instead of reserving the entire file.

In the past year urchin.js has only been updated once, yet the Last-Modified header reflects an updated date every time.

The problem happens when requests for the urchin.js file on google-analytics.com spike, even with load-balancing technologies which are obviously in place. When this happens your browser makes the request for the urchin.js file, but instead of an immediate connection and transfer of the file you get a lagging transfer.

One reason is because the server that the urchin.js file is served from does not allow persistant connections.

Another big big reason is that even though Cache-Control headers are correctly set by google-analytics when serving urchin.js, Instead of responding to an If-Modified-Since header correctly with a 304 Not Modified header, indicating the file has not been modified, google-analytics instead returns the entire urchin.js file again, thus rendering the cache-control void.

You can see this problem with a wireshark capture.

GET /urchin.js HTTP/1.1
Accept: */*
Referer: http://www.askapache.com
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Tue, 20 Mar 2007 22:49:11 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SU 2.011; .NET CLR 1.1.4322; .NET CLR 2.0.50727; Alexa Toolbar; .NET CLR 3.0.04506.30)
Host: www.google-analytics.com
Connection: Keep-Alive

Code (markup):

HTTP/1.1 200 OK
Cache-Control: max-age=604800, public
Content-Type: text/javascript
Last-Modified: Tue, 20 Mar 2007 22:54:02 GMT
Content-Encoding: gzip
Server: ucfe
Content-Length: 5675
Date: Sat, 24 Mar 2007 18:23:12 GMT

Code (markup):

Of course you should implement your own caching scheme for best results.


So there are 2 pretty major things that you can eliminate by using a locally hosted version of the urchin.js file.

1. Enable persistant connections
2. Send correct 304 Not Modified headers

Still, this issue only becomes an issue if you notice lags from the google-analytics site, which happen from time to time.

 

Nice method. Thanks for sharing it. I will definitely try it

 

Hey this is something that can make the whole analytics program work faster..

 

Does caching affect the Google Analytics script, so that the statistics are bad ?

 

Nope. Heres the caching I use for js files in my htaccess.

# 3 HOUR
<FilesMatch "\.(txt|xml|js|css)$">
Header set Cache-Control "max-age=3600"
</FilesMatch>

Code (markup):