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.
4 rating from 20 votes
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?
(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?
Recommended for graphing times of individual page elements (images, ajax calls, css files, etc.):
- IBM Page detailer
- Firebug “Net” tab
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.
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.
Second and third the recommendations for Firebug’s net tab. It’s very useful.
Tom, that’s a great point about ‘perceived load time.’ The really cool thing about Michael’s tool, and I wrote this up a bit on my blog tonight, is that it moves us in the direction of considering performance within the browser, from the end user’s perspective. I think that’s the only way to answer the types of questions you are asking.
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.
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.
Yeah, I’d recommend using Firebug - one less thing to install. :|
________________
Full Download | Free web directory | موبایل ، کامپیوتر