I just recently came across a great article titled How tracking scripts affect page loads… can Google Analytics kill my web app?:

This post explains script blocking, and then shows how to safely setup a tracking script or any external script, such as Google Analytics or Quantcast, to not block page loads or other javascript handlers on your site.

It’s a great read and provides a clear explanation on how third party components (everything from advertisements to analytics to content widgets) can slow your site down. JavaScript includes have been commonly used in websites for coming on a decade, but there are still many people who don’t understand the destruction a rogue script can cause to user experience.

One such example of that kind of destruction recently happened to customer of ours who ran an advertisement during the Super Bowl. In the weeks and months leading to the event, they had done massive amounts of tests and verified that their data center could easily handle 2.5 gigabits per second or more.

They were more than prepared and, overall, the event went off without a hitch. However, there was one minor problem that did plague their launch: a third party that served a component on their site couldn’t keep up with the load.

It turns out that one page (unfortunately, an important one that allowed visitors to search for their products) included an inline JavaScript file hosted externally. This included file was added at the last minute and didn’t get subject to the intensive testing that the rest of the site had gone through.

When the external site went down, visitors’ browsers would timeout after 1-2 minutes of trying to fetch that content before finally firing the important onload event in the browser. Nothing hosted by the company had a problem, but yet it still affected the user experience.

To make matters worse, the customer did have certain JavaScript that fired on the onload event. This JavaScript added rich functionality, such as making a calendar pop up when clicking on a date field. Because of the 1-2 minute delay, this functionality wasn’t available immediately, causing the experience to deteriorate.

In addition to all the guidance given in the aforementioned article, there are two things they can do to avoid this next time:

• Remove the third party reference entirely. In this case the reference was to some JavaScript that in turn produced a “Follow me on Twitter” image. That image could have easily been hosted in their own data center, which had been tested thoroughly.
• Take advantage of the “on content ready” psuedo event. Most modern JavaScript frameworks support a non-standard event that will fire before onload. Most of the time, this is much more desirable as it means that the JavaScript will fire closer to when the user sees content in their browser – not just when all images and JavaScript has been downloaded.

The “on content ready” psuedo-event doesn’t have an official name, but a lot of people also refer to it as “on DOM ready”. YUI, Dojo, Prototype, jQuery, and many others support it, so be on the lookout.

Tweet This Post 

3rd party widgets · Performance

Often when it’s time to run a load test or turn on website monitoring, you don’t necessarily want the transaction hitting all your third party components on the page.

For example, you don’t want your analytics software to record the visits as real visitors, since that would skew your marketing metrics. Likewise, you don’t necessarily want advertisements served up, especially if the ad vendor uses “click-through rates” (CTR) to optimize ad prices and a load test would artificially drive down the CTR.

While there are vendor-specific actions you can take to deal with this problem (ie: we cover Google Analytics here), sometimes the easiest solution is to modify your script so that the request is never made in the first place.

You can do this for both Real Browser User (RBU) and Virtual User (VU) scripts using some new APIs that we recently rolled out. They allow you to whitelist or blacklist certain hosts from having actual HTTP requests sent to them.

For example, suppose you want to exclude all requests to www.google-analytics.com from your website monitoring or website load test. Your script would need to do something like this:

var selenium = browserMob.openBrowser();
var c = browserMob.getActiveHttpClient();
 
c.blacklistRequests("http://www\\.google-analytics\\.com/.*", 
                    200);
 
browserMob.beginTransaction();
browserMob.beginStep("Step 1");
 
// rest of test...

This would ensure that any HTTP request to Google Analytics would be bypassed immediately and a fake 200 response code would be returned instead.

Sometimes it’s easier to whitelist “good” hosts instead of blacklisting specific ones. This is often the case for advertising networks, which tend to host content from dozens of different domains.

var selenium = browserMob.openBrowser();
var c = browserMob.getActiveHttpClient();
 
c.whitelistRequests(["http://www\\.example\\.com/.*", 
                     "http://images\\.example.com\\.com/.*"], 
                    200);
 
browserMob.beginTransaction();
browserMob.beginStep("Step 1");
 
// rest of test...

In this example, we are allowing all requests to www.example.com and images.example.com to go through, but faking any other request with an immediate 200 response code.

These whitelist and blacklist APIs are just one example of the powerful scripting you can do using the BrowserMob API and scripting environment. We encourage you to review the entire API documentation from time to time, as well as contact us if you ever have questions about them.

Tweet This Post 

3rd party widgets · API · Google Analytics