Today we are pleased to announce several major improvements to BrowserMob’s monitoring service, as well as a brand new website:

• Drastically improved charts, including object-level performance charts
• Three new locations: New York City, Amsterdam, and Singapore
• Raw HTTP header captures for any failed transaction
• A brand new website, including a major update to our free Instant Test tool

Please check them out, or continue reading for more information.

Improved Charts

The number one feedback we received with our monitoring product was that while it was fun and easy to script real browsers, the charting left a lot to be desired. So we completely overhauled the charts, making them faster and more responsive. They also now break down each monitoring location use rich, vibrant colors, making it easy to see if you have performance issues in certain geographies.

In addition, we introduced object-level charting. Now when you view an individual transaction you’re going to be able to drill down to view individual object performance over time. Simply click on that element and you’ll be presented with a chart that plots response time for that individual HTTP request, broken down by each geography.

Three New Locations

We’ve added support for three new cloud-based locations, all powered by Voxel, a fantastic CDN and cloud computing provider. They are: New York City, Amsterdam, and Singapore. These locations are currently in beta and their long-term status will depend on how well they perform. So please try them out and let us know what you think. This brings our total locations up to seven, as we already support San Francisco, Dallas, Washington DC, and Dublin.

Raw HTTP Captures

In order to give you better root-cause analysis of monitoring failures, we now give you the ability to view the raw HTTP wire traffic for any failed test. This will tell you what HTTP headers were sent for every single GET or POST issued by the browser. Whether you leverage a large CDN or run a one-server deployment, this additional information should be very useful.

Brand New Website

Finally, we extremely happy to have rolled out a new website and complete UI overhaul for our monitoring and load testing services. In addition, we’ve completely rewritten our free Instant Test tool to make it faster, easier to use, and provide more actionable data analysis. Please try it out and let us know what you think!

Tweet This Post 

Monitoring · Performance

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

Over the last few months Google has continued to focus on performance as a key message to developers. From their “Let’s make the web faster” initiative on Google Code, to their public DNS service, to the constant focus on performance by their Chief Performance guru, Steve Souders, it’s clear that Google wants people to have a faster experience on the web.

This makes sense: the faster the web, the more people will use it and be more likely to search and click on ads. In fact, in an interview with Web Pro News in November last year, Matt Cutts (head of Google’s webspam team) casually mentioned that in 2010 Google may give search ranking preference to sites that load faster. Om Malik went on to discuss whether this was a good idea or not.

More recently, Google opened up a new “Labs” feature in their Google Webmaster Tools that actually shows you the performance of your site as measured by the Googlebot. This move is further evidence that Google is indeed going to shift to making performance part of it’s ranking routine if it hasn’t already. See a screenshot of what you can expect to see:

In addition to the above chart, there is also some basic analysis and recommendations on how to improve performance, similar to what Page Speed and YSlow recommend. While it is a good start and provides the clearest view of how Google perceives your site’s performance, the data is still rather basic.

As such, when measuring and optimizing page load times we’d still recommend you work with a more in-depth tool such as Page Speed and YSlow. And, of course, for website monitoring and website load testing, we’d have to recommend BrowserMob

Tweet This Post 

Firebug · Google · Google Public DNS · Page Speed · Performance · YSlow