PDA

View Full Version : Speed Up Google Analytics on your site


produke
3-23-07, 09:29 PM
Learned a cool way (http://www.askapache.com/2007/webmaster/faster-google-analytics-with-a-local-urchinjs.html) 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>

Official Google Position on locally hosting urchin.js (http://www.google.com/support/analytics/bin/answer.py?answer=43183&query=urchin.js&topic=&type=)
Can I host the urchin.js file locally?

While you are welcome to download the file to examine, we do not recommend that users serve the urchin.js themselves.

Most people wish to host urchin.js locally in order to avoid making their users download it from Google every time they request a page. However, urchin.js is designed to be downloaded once from Google and is then served from the visitor's cache.

Referencing the urchin.js file from Google's servers will ensure that you are using the most current version, allowing you to easily obtain new features and other enhancements as they become available. This will help make your reports as accurate as possible.

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

Notice the Cache-Control (http://www.askapache.com/2006/htaccess/speed-up-sites-with-htaccess-caching.html) 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>
its this
<script src="/z/j/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-333153-x";urchinTracker();
</script>


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 (http://www.askapache.com/2007/webmaster/faster-google-analytics-with-a-local-urchinjs.html)


So what do you think? cool huh!

tpoynton
3-24-07, 08:22 AM
I dont even use Google Analytics, but if I did, this would be extremely useful! Thank you for sharing!

produke
3-24-07, 02:56 PM
There are 2 pretty major things that you accomplish by hosting urchin.js locally

You Enable persistant connections
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 (http://wireshark.org) capture (http://www.askapache.com/2007/htaccess/sniff-http-to-debug-apache-htaccess-and-httpdconf.html).

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

Of course you should implement your own caching scheme (http://www.askapache.com/2006/htaccess/speed-up-sites-with-htaccess-caching.html) 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.

Enable persistant connections
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.