[kevinconroy]

Here are two of my favorite tricks. You can do this just after you set your account ID:

        <!-- Async Tracking Code - http://code.google.com/intl/en-US/apis/analytics/docs/tracking/asyncTracking.html -->
	<script type="text/javascript">
	  var _gaq = _gaq || [];
	  _gaq.push(['_setAccount', 'YOUR ANALYTICS ID GOES HERE']);
	  _gaq.push(['_trackPageview']);

          //*******************
          // Trick #1: Track page load time in Google Analytics
          // (note: only works for HTML5 browsers)
          //*******************
	  _gaq.push(['_trackPageLoadTime']);

	  (function() {
	    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
	    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
	    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
	  })();
	  
          //*******************
          // Trick #2: Add a Javascript error handler so that it creates an event in Google Analytics
          // whenever there's a CLIENT-SIDE javascript error
          //*******************
	  window.onerror = function(message, file, line) { 
	     var sFormattedMessage = '[' + file + ' (' + line + ')] ' + message; 
	     _gaq.push(['_trackEvent', 'Errors', 'Browser', sFormattedMessage, null, true]);
	  }
	</script>

Update: Included complete GA code to address any confusion on order and values available in stack.

[gulbrandr]

According to this page [0], _trackPageLoadTime() is deprecated because site speed reporting is enabled automatically for all users.

Update: your 2nd trick is still relevant though

[0] https://developers.google.com/analytics/devguides/collection...

[kevinconroy]

Thank you! I was unaware of this change.

[rfergie]

As others have noted, _trackPageLoadTime is depreciated.

However, Google Analytics only automatically samples the page load time for 1% of visitors.

To change this call

_gaq.push([‘_setSiteSpeedSampleRate’, 100]);

before tracking the pageview. This will sample 100% of users for the site load time.

https://developers.google.com/analytics/devguides/collection...

[iamchrisle]

Very good point! Just be careful...

- Google will take a lot longer to report your data if you do this. - Google also has data limits. If you're experiencing 10k+ pageviews a day, you will probably run into the limit and it will stop reporting stuff.

http://support.google.com/analytics/bin/answer.py?hl=en&...

[jessep]

You should consider including a userid of some sort with the error reporting. It can let you debug down esoteric, hard to reproduce errors reported by users, which are otherwise almost impossible.

[iamchrisle]

_trackPageLoadTime is deprecated. It's already enabled by default, so you don't need that line.

Place this stuff in the head tag rather than the bottom. It's async code and placing it closer to the top you can make sure you're setting up tracking the page as soon as possible.

[bluetidepro]

> "// Track page load time in Google Analytics"

After adding that, where does that appear in the Google Analytics dashboard? Can you explain further how that works? Thanks!

[kevinconroy]

It's under Standard Reporting -> Content -> Site Speed

The GA code will track client side page load time (DOM fully loaded) across your site. You'll get site-wide averages and you'll also get to drill in on slow pages. This doesn't work for every single browser (last I checked it only worked for browsers that support HTML5), but it still provides a good sample size.

It's also important to do this as Google Webmaster tools dropped support of the Site Speed lab which shows you how fast Google thinks your site is ( <1.5 seconds user DOM load is considered faster, >= 1.5 seconds is "slow"). If you're trying to improve your Google ranking you need to be tracking how fast Google thinks your site is. (Also, fast websites are great for lots of reasons, not just Google ranking.)

See also: http://analytics.blogspot.com/2011/05/measure-page-load-time...

[iamchrisle]

In my experience Google's measures are 1-2 seconds higher than what I personally experience. Not sure why. Take it with a grain of salt and look for trends.

Googlebot seems to give up crawling your site after about 14 seconds :) You might see that reported in GWT.

[cooperadymas]

There are a lot of reasons this may be. Your Internet may be faster than your average user's. You may be closer geographically to your server. Different browsers will show different load speeds. The site may be cached for you most of the time.

I know you weren't actually asking, but I figured it's worth stating this for someone else who might experience the same thing. Load times do vary greatly. Digging down into the Analytics can show you where/why they vary. And as you said and as always with Analytics, look for trends more than exact figures.

[iamchrisle]

+1000 I'll tend to look at the speed coming off the server instead. At least I know that I can control 100%. If the user is on a dial up modem, not my problem ;)

[tomfakes]

There are many things you can do to improve the performance of your website, even to people with dial up - or worse - Mobile!

Compress data with gzip is probably the big one for modem users, but also batching scripts and CSS together, reducing image sizes, re-arranging code to reduce blocking during rendering.

These are all things under your control, and with current mobile browsers, these are things you really must care about

[kevinconroy]

Getting user perceived page load time down is vital for most sites. You'll see your bounce rate drop, pages per visit rise, and conversion rates go up. A better experience for your users is always better for you.

You can do something to make like better for those on mobile and dialup with server settings, image compression, and the like. You can't change their connection speed, but you can focus on their experience.

[kirchhoff]

Best to check for the existence of _gaq before pushing elements into it, or the user might get a reference error.

[kevinconroy]

I just updated by code segment to show where I call this (it's right after declaring _gaq).