Tuesday, February 13th, 2007

WebWait: Time your Ajax apps

Category: Performance, Showcase, Utility

Our own Michael Mahemoff has created WebWait. We will let him take it from here:

I wanted a portable, consistent, way to benchmark Ajax web apps, that would show how long the wait is (though it’s useful for any app, especially if there were a lot of images, for instance). Using a command-line tool like curl doesn’t cut it as a proper simulation. WebWait has the following benefits:

  • Runs in a browser. You get actual load times in the same client web users are running, not simulated times.
  • Runs in multiple browsers. There are plugins that do this, but as well as the installation overhead, they are usually specific to one browser. With WebWait, you can just cut-and-paste the same URL into different browsers. (No Safari yet as it doesn’t listen to iframe onload ???.)
  • Respects your cookies and authentication – If you can access a URL in a web page, you can benchmark it with WebWait, since it loads the page in an IFrame. Trying to set up cookies for use with a command-line tool like Curl is hard work. Doing it with a plugin is usually impossible. Doing it with a third-party website is dangerously insecure.
  • Accesses sites behind a firewall. Again, as long as you can access a web page, it doesn’t matter if it’s on your local PC, your LAN, or the open internet.

Quick feature list as it stands right now:

  • Basic functionality: Type a URL, see how long it takes to load.
  • Option: Set the delay between calls. WebWait will call the website multiple times and provide an average load time.
  • Option: Set the number of calls before ceasing activity.
  • Ability to pause.
  • Partially transparent lightbox eye candy.
  • Unique URLs – it’s Ajax, but that shouldn’t stop you from bookmarking and sending URLs with details of the website being tested. Incidentally, implementing this rare but highly useful feature took three lines of Javascript.

Have fun. Any comments/suggestions, please let me know!

See the FAQ for more info.

Posted by Dion Almaer at 10:13 am
7 Comments

+++--
3.8 rating from 25 votes

7 Comments »

Comments feed TrackBack URI

This is interesting, but two questions:

(1) what happens in an AJAX app when there
is asynchronous arrival of information?

(2) does this work (we suspect not) when you want
to measure the total arrival times of individual page
components?

Comment by Edward Miller — February 13, 2007

(1) It will ignore any new asynchronous arrival of info (after all, that could go on indefinitely). All it does is time how long until the IFrame’s onload event fires, which means any XHRs fired off on page startup or later will be ignored.
(2) Sorry, I don’t follow what you mean by that?

Comment by Michael Mahemoff — February 13, 2007

Recommended for graphing times of individual page elements (images, ajax calls, css files, etc.):

– IBM Page detailer
– Firebug “Net” tab

Comment by Jonathan Aquino — February 13, 2007

This is a great idea, although after using it, it dawned on me that even this time isn’t the “actual” time a user has to wait.

For example, I pulled up TechCrunch in the tool and it told me 12 seconds. It didn’t actually take me, the end user, 12 seconds before I could start using an interacting with the site. A lot of that extra time was pulling down images that weren’t really interfering with my ability to use the site. In fact, some of the images were scrolled out of view, so they didn’t even matter. As a user, I wouldn’t even have noticed.

It’s a cool idea though, and I totally agree that tools like curl and httperf don’t tell the whole story.

Comment by Tom — February 13, 2007

Yeah, I’d recommend using Firebug – one less thing to install. Jonathan is right, the “net” tab is REALLY good for testing load speeds of website elements in detail.

Comment by markus941 — February 13, 2007

Guys, thanks for the feedback.

Tom, correct about perceived load time, ultimately that’s all what matters. In some respects, the IFrame is more accurate than other techniques, but not totally if the page is image-heavy as. WebWait works best for Ajax-heavy sites where JS processing is the bottleneck. The idea actually came to me while writing Quizr.com, where a large quiz can take a while to load due to all the event registration. I was using the FasterFox plugin for profiling, but wanted a consistent tool across browsers.

Firebug is awesome. Seconded, Thirded, Fourthed!!! With its feature set, there’s not much reason to use webwait over firebug if you have it installed. One benefit of WebWait right now is the ability to cut-and-paste a URL and try it in IE, or send it to a friend.

Comment by Michael Mahemoff — February 14, 2007

before firebug was around, I always used Charles. It’s a local proxy that lets you look into the data you download, and takes the time as well. Of course, the time the browser itself takes to calculate and display is missing here, but that’s, in my case, pretty much negligible.

Comment by Matthias — March 6, 2007

Leave a comment

You must be logged in to post a comment.