HttpWatch Blog

Follow Up: Asynchronous Google Analytics is Better but Not Faster Even with IE 6 and 7

Httpwatch Blog — Thu, 12 Aug 2010 15:10:58 +0000

In our last post Asynchronous Google Analytics is Better but Not Faster, we ran some tests using HttpWatch in Firefox 3.6 and IE 8 to see if the asynchronous version of the Google Analytics (GA) script was really faster as many have claimed.

We found the following:

Changing from the synchronous to asynchronous GA snippet make no significant difference in page load time over a typical broadband connection
When we tried simulating a slow download of the ga.js file, we did find that the asynchronous version of GA isolated the page from this potential performance problem - but only in IE.
When we simulated a slow download of the GA image beacon, we did not see a difference between the two versions of GA. In IE, the image always downloaded in the background without holding up the page load event. In Firefox, a slow GA beacon always held up the page load.
We found that the asynchronous version of GA completed the GA beacon request much sooner on slow pages allowing the analytics data to be collected even when the user left the page early

Our overall conclusion was that due to point 4) the asynchronous version of GA was worth using because you were more likely to get analytics data from slow pages. The only potential performance benefit we found was in item 2) but we ignored that because:

It only applied to IE
There’s a high chance the ga.js file will be cached (unlike the beacon file) before the user visits a page
In our experience the components of GA always download quickly, often in a 100 ms or less on a typical broadband connection

One of the comments we received was that we should really have tested with IE 6 and 7 as those browsers are more prone to script blocking issues.

So, here are the condensed results of running the same tests in IE 6 and 7:

Do Pages Load Faster With Asynchronous Google Analytics in IE 6 and 7?

As before there was no significant performance advantage. Here are the IE 6 time charts with an empty cache:

And the IE 7 charts with a primed cache:

Would Google Performance Problems Have Less Impact With Asynchronous Google Analytics in IE 6 and IE 7?

We found that IE 6 and 7 behaved the same as IE 8 when we simulated the slow download of the GA image beacon. It didn’t matter which version of the GA script we used. The image always downloaded in the background without affecting the page load time:

When we tried slowing the download of the ga.js file, we found that IE 6 and IE 7 benefited from the asynchronous version of GA in the same way as IE 8:

Is Data More Likely to be Recorded by Asynchronous Google Analytics During Early Page Exits in IE 6 and IE 7?

Again, we saw the same behavior as IE 8. Using the asynchronous version of GA increased the chance of collecting analytics data when a user left a page early.

Conclusion

We found no differences in our tests with IE 6 and IE 7 compared to IE 8. Asynchronous GA is worth using because it increases the chance of gathering data from slow pages, but you shouldn’t expect to see faster page load times unless you encounter a slow, uncached ga.js file in IE.

So why doesn’t asynchronous GA deliver significant performance gains as widely claimed? We believe it is down to the following factors:

The synchronous version of the GA script is included at the bottom of the tag minimizing it’s impact on the rest of the page
The files used by GA typically download so quickly that in most cases any improvement has minimal impact on the overall page load time
The asynchronous loading techniques don’t seem to work in Firefox for either component and only help with the ga.js file in IE

Asynchronous Google Analytics is Better but Not Faster

Httpwatch Blog — Thu, 29 Jul 2010 16:27:16 +0000

In December 2009, Google launched the asynchronous version of the Google Analytics script. The update aimed to address potential script blocking problems that have been extensively researched and reported by Steve Souders at Google.

Steve’s blog post about the new asynchronous loading of Google Analytics identified three potential benefits:

Your pages should load faster
Availability or performance problems at Google should have less impact on your site
Analytics data is more likely to be collected if a user leaves a page early

Before applying the change to our web site we decide to compare the new and old versions of the Google Analytics scripts using HttpWatch 7.0 .

The following sections describe what has changed in the asynchronous Google Analytics script and the tests we performed to compare it to the traditional synchronous version.

What has Changed?

Google Analytics collects data using two components on a page:

A javascript file script file that is loaded from http://www.google-analytics.com/ga.js
A 1×1 pixel image beacon (http://www.google-analytics.com/__utm.gif) that passes data back to Google in query string parameters

You enable Google Analytics on a web page by calling a page tracking function in ga.js. This function automatically gathers analytics data, such as operating system and browser versions, then generates the call to the image beacon.

The difference between the two ways of loading Google Analytics is in the way that the script file is loaded. In the traditional synchronous version, two small script tags are added at the end the page’s tag:

...
  <script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ?
    "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost +
    "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  script>
 
  <script type="text/javascript">
    var pageTracker = _gat._getTracker("XX-XXXXXX-X"); // Your GA id
    pageTracker._trackPageview();
  script>

...

The first script tag ensures that the correct HTTP or HTTPS version of the qa.js file is loaded. The second script tag then calls into the javascript file triggering the beacon image download.

These two script tags are placed at the end of the body tag to ensure that they don’t hold up the download of any other resources on the page. The disadvantage of doing this is that the analytics call may not be triggered if the user exits the page before it has completely downloaded.

The asynchronous version of the Google Analytics loading code uses a single script tag at the end of the page’s :

...
 
  <script>
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'XX-XXXXXX-X']);
    _gaq.push(['_trackPageview']);
 
    (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);
 
    })();
  script>
 
head>
...

It sets up the parameters required to make the call into ga.js but doesn’t invoke the function directly. A script element is added to the document allowing asynchronous download without blocking other elements of the page. The HTML 5 async attribute is also set on the script tag for browsers that support it.

Once the ga.js file is loaded and executed it looks for an array variable called _gaq and executes the function with the previously specified arguments.

Do Pages Load Faster With Asynchronous Google Analytics?

To try this out we created a version of our Download page using both versions of the Google Analytics loading code. We first tried the synchronous version with an empty cache in IE to simulate a new visitor to the page:

And then with the asynchronous version:

The page load times were dominated by other components on the page. Using the asynchronous version of Google Analytics didn’t really make any difference.

We tried the same tests with a primed cache to see if there would be a greater impact when the page was loaded during a repeat visit. First the synchronous version:

and then the asynchronous version:

Again there was practically no difference in the page load time of the page allowing for variability in our tests.

The reason for that is that calls to Google Analytics are incredibly fast (usually around a 100ms or less) and the download of the image beacon doesn’t block other components because it uses a different hostname.

We tried Firefox 3.6 and got almost the same results.

Conclusion: Google Analytics is so fast that you won’t see any significant improvement with the asynchronous loading version.

Would Google Performance Problems Have Less Impact With Asynchronous Google Analytics?

For this test we needed to simulate performance problems at Google. We did this by modifying the standard script snippets to call our own ASP.NET versions of the Google files that served the same content but added a 5 second delay.

For example, here’s the ASPX file we used to serve up a local copy of ga.js:

<%@ Page Language="C#" Debug="true" %>
<%@ Import Namespace=System.IO %>
<%
  System.Threading.Thread.Sleep(6000);
  Response.AddHeader("Content-Type", "text/javascript");
  Response.WriteFile( ".\\ga.js");
  Response.End();
%>

We did something similar with the Google __utm.gif file so that we could add delays to either component.

Using our slow simulation of ga.js in IE 8 we found that the page’s onload event was delayed with the synchronous version of the Google Analytics:

This caused the IE 8 to display the spinning icon in the current tab:

and a “Waiting…” message in the status bar:

indicating to the user that the page was not fully downloaded.

We then tried using the slow version of the __utm.gif image file. This didn’t cause a problem in IE 8 as the page loaded successfully but continued to download the image beacon in the background even with the synchronous version of Google Analytics:

Firefox 3.6 didn’t cope as well. Delaying the download of the beacon file with the synchronous loading code had the same effect as delaying the ga.js file - the page load was delayed, the spinning tab icon was displayed and the status line indicated that it was waiting for data.

We then tried the asynchronous version of the analytics loading code. Delaying either the ga.js or utm.gif file had no effect on the loading of the page in IE; effectively hiding the issue from the web site visitor:

Surprisingly, the asynchronous version of the analytics code made no difference to Firefox 3.6 when we simulated slow downloads of the Google components:

Conclusion: Using the asynchronous load made IE 8 more robust to performance problems in the loading of qa.js. Otherwise it made no difference. In reality, ga.js is often cached anyway making it the less likely of the two components to be subject to performance problems.

Is Data More Likely to be Recorded by Asynchronous Google Analytics During Early Page Exits?

To test this potential benefit we changed our test pages to include a slow loading script file at the top of the body tag. The idea was to emulate what might happen on your page if a third party component, such as an ad script, started to slow down.

The script tag we added called an ASPX file than delayed 6 seconds before returning an empty script block:

<body>
  <script type="text/javascript" src='http://veryslowdownload/ad.aspx'>script>

This stopped our page being displayed for six seconds.

Using the synchronous version of the loading code in IE 8 and Firefox 3.6, we found that the Google Analytics beacon image was not downloaded if the user gave up and went elsewhere:

The asynchronous loading of Google Analytics solved this problem in both browsers. The image beacon was downloaded almost immediately even though the page was blocked by the slow script tag:

Conclusion: The asynchronous version of Google Analytics helps to ensure that analytics data is gathered in IE and Firefox when the user leaves a page early.

Should I Use the Asynchronous Version of Google Analytics?

Yes, but not for the reasons you might expect. It’s unlikely to make any difference to how quickly your pages load.

The main reason to use it is that you are more likely to get analytics data if a user leaves a page early.

HttpWatch Version 7.0 is Available For Download

Httpwatch Blog — Mon, 07 Jun 2010 08:00:50 +0000

HttpWatch version 7.0 has been released and is now available for download.

Any customers eligible for a free upgrade to HttpWatch Professional can install the latest version using their existing license key. If you’re not sure whether your license will work with version 7.0 go to Help->Check For Updates in HttpWatch and it will show you any available updates or upgrades.

What’s New?

Page Level Events

Page level time charts now include lines to indicate when events were raised during the loading of a page:

Improved Grouping of Requests during Page Load

Requests occurring after the page onload event are now grouped with the requests recorded during the initial loading of the page:

HttpWatch Detects and Highlights Potential Problems

HttpWatch now examines each request and issues warnings where problems relating to performance, security or functionality are detected. Requests that have warnings are highlighted with a new Warning column marker:

and a new request level Warnings tab shows the details of each potential problem:

There’s also a new Warning tab in the Summary window that summarizes the occurrence of each type of warning in a page or set of selected requests:

Customizable Grid Controls

Right clicking on a grid’s column headers opens a customization menu:

For example, you may want to increase the font size if you are using HttpWatch in a demonstration:

New Data Columns in the Request Grid

There’s now more than thirty columns to choose from in the main request grid covering almost every data item that is available in HttpWatch:

Customizable CSV Export

The CSV output now can now be customized to include the data fields that you need:

Data Tips Help You Understand The Recorded Data

Data tips are now displayed when you hold the mouse pointer over an item such as an HTTP status code:

Or a header value saving you the trouble of looking up what the value means:

New Icon Based Type Column

The new icon based type column saves space and provides an instant visual marker for different types of content. The data tip shows the underlying mime type:

Coloring of Result Column Values

The result column now uses red to indicate errors and gray for (Cache):

More Information About Cookies

The cookie tab now displays the HttpOnly and Secure flags for each cookie; including cookie values that were sent to the server. The source column shows whether the cookie value was returned from the server, set by Javascript or saved in the cookie store by a previous session:

Improved Support For HAR Files

HTTP Archive (HAR files) can now be:

Saved as HttpWatch log files (.hwl)
Open using the HttpWatch automation interface
Re-exported in CSV or XML formats

Improved Automation Interface

The automation interface allows HttpWatch to be controlled from programs written in almost any programming language (e.g. C#, VB.Net, Ruby, Javascript). In version 7.0, this interface has been extended with new classes, properties and methods to support:

Page level events
Warnings
Export of customized CSV output
HTTP Archive (HAR) files
Image dimensions

The documentation is also improved with a new format and object relationship diagrams:

Uploaded File Type on POST Data tab

The content type of uploaded files is now shown in a separate column in the POST Data tab:

Compatibility with Version 6.x

The HttpWatch log file format (HWL) has changed in version 7.0 to include support for page level events and imported HAR files. Files can be saved in HttpWatch 5.x/6.x format in case you need to share files with someone running an older version of HttpWatch.

The automation interface maintains backwards source compatibility with interpreted script clients and binary compatibility with existing compiled clients (e.g. C#, C++, VB.Net) .

HttpWatch 7.0: Spot the Differences!

Httpwatch Blog — Fri, 28 May 2010 14:21:55 +0000

Rather than the usual product release statement, we thought we’d try something a little different.

Spot the New Features and Win a Single User license

Here’s a screenshot of HttpWatch 7.0 that will be released on Monday, June 7th 2010:

There’s at least four new features visible in this screen shot. Some of them are quite subtle, so you may want to fire up HttpWatch 6.2 for comparison.

The first three people to correctly name four new features will win a free single user license for HttpWatch Professional.

UPDATE: Sorry the competition is now over. The winners were:

宗永涛(Zong Yongtao)

Alex McCubbin

Greg Goddard

Rules

Post your entry as a comment to this blog post
Put your email address in the email field but not the comment text. That way we can contact you without everyone seeing your email address. (We won’t use your email address for any other purpose)
We won’t name or share any information about the winning entries unless you are happy for us to do so
Once we’ve got three correct entries we’ll edit this post to indicate that the competition is closed
We’ll then contact the winning commenters and send them a license key. It doesn’t have to be for you; it can be for a friend or colleague.
The competition isn’t open to beta testers or anyone associated with Simtec Limited
Our decision is final and any entries after the competition has closed will be ignored