A couple days ago, Google Analytics finally got around to incorporating web performance measurements in Google Analytics with their new “Site Speed” feature. Almost seven months ago, we posted about this exact same idea of pushing JavaScript-based web performance timings into GA (using custom variables) to gain understanding of the business impact of slow page load times. We provided our more adventurous readers with an experimental code fragment^[1] to try it themselves. And long before that, we provided an official Yottaa / Google Analytics integration to show GA business metrics and Yottaa Insight performance data in the same place on yottaa.com. I thought it might be helpful to distinguish between these three approaches, and I also found it interesting to compare our experimental mechanism for pushing performance data into GA with the brand-new, GA-native Site Speed feature.

Yottaa and Google Analytics: What We Already Support

First, to avoid any confusion, let me show you what we already officially support on Yottaa.com:

We pull GA metrics like bounce rate and visits out of Google (using the Google Analytics Data Export API and its standard oAuth integration), and visualize them along with Yottaa Insight performance metrics. This is free, and is something we’ve supported for months. This official Yottaa / GA integration is unrelated to the new GA Site Speed feature, and does not require you to make any changes to your standard Google Analytics code. It’s also completely unrelated to our aforementioned experimental JavaScript / GA custom variable piggyback approach (which is interesting and useful to some, but is not at this time part of the Yottaa Insight product). Hopefully that’s clear. Now we can get on to comparing the new Google Analytics Site Speed feature with our experimental JavaScript.

Custom Variable Piggybacking (A Yottaa Idea from Oct. 2010)

This approach puts a simple JavaScript timer in the very head of the doc and uses the onload event to measure the basic page load time. Then it uses theW3C Nav Timing API for those browsers that support it (Chrome 6+ and IE9, so far) to obtain more accurate and detailed performance data. Finally, the collected timing data gets injected into GA via custom variables. See the original blog post for a thorough walk-through, and the updated gist code fragment for the latest version of the code.

For visualization, we haven’t incorporated these custom variables’ data into anything on yottaa.com, but it’s not too hard to do something like this in a spreadsheet program like excel:

Pros:

• Provides at least basic measurement for all browsers with JavaScript enabled
• Provides detailed performance measurements using W3C Nav Timing API in browsers that support it
• No new beacon / HTTP request

Cons:

• Requires use of custom variables (of which you can only have a few)
• Reporting inside GA, on custom variables, is not good; decent visualization requires pulling data out of GA
• Requires modifying your GA code
• Introduces a small observer effect

Google’s Native Site Speed feature

Google uses the W3C Nav Timing API too, and if it’s not supported, looks for similar hooks for start time in the Google Toolbar. If that’s not present… no measurement occurs! So you’re getting fine-grained data, but for only a sampling of your users. Users of IE 6, 7 or 8, Safari, Opera or Firefox, without the Google Toolbar installed and enabled, are not included in the measurements. From the looks of it, perhaps 10% of page requests are sampled for Site Speed measurement. If it were a random sample, that might be just fine — but it’s not a representative sample, as users of these modern browsers are in all likelihood running newer, faster hardware, and possibly using better Internet connections. It’s not clear how much this skews the data, but there is almost certainly some effect.

Pros:

• Better reporting within the Google Analytics dashboard, compared to data pushed into custom variables
• Provides detailed performance measurements using W3C Nav Timing API in browsers that support it
• Access to Google Toolbar -based timing data may provide accurate start times not otherwise available for browsers that don’t support W3C Nav Timing API

Cons:

• Only collects performance data from a non-representative sample population (IE9, Chrome and Google Toolbar users)
• Triggers an additional HTTP request
• Requires modifying your GA code
• Introduces a small observer effect

Despite these shortcomings, this new Google Analytics feature is clearly a Good Thing^TM. It underscores the importance of WPO, and raises awareness of the business impact of slow websites. The more measurement and data everyone has, the better!

Looking ahead

We assume Google will add the new Site Speed data to the GA data export feed. When that happens, we may work to incorporate that in our visualizations too, e.g. alongside any data injected using the custom variable piggyback approach, and of course our existing Yottaa Insight metrics. I’ll be sure to post about such new Yottaa Insight features when the time comes.

Till then, as always, we’re interested in your feedback. I’d specifically love to hear from you about these questions:

• Do you plan to implement the Site Speed feature in your Google Analytics integration?
• Have you already done so?
• Have you seen any interesting results?
• Were you aware of the custom variable piggybacking technique?
• If you’re measuring this stuff, how does your site’s performance correlate with your users’ behavior?
• How important to you is the visualization of performance metrics alongside traditional website metrics?