It started as an off-hand remark by my buddy, Ricardo: “You should make a tool that can load two web pages side by side so you can see which one loads faster.” I backpedaled a little at first, the way an overworked programmer does when someone suggests sticking another iron in the fire: “Um, I don’t know if that would really work out without writing a browser plugin.” This, of course, meant something more like, “Dude, I’m lazy, and that sounds like a lot of work just to make another toy for our sales and marketing guys.”
Ricardo had me though, it would be cool to load two pages side-by-side and see the differences in real time. Dan, one of the aforementioned sales and marketing guys, was grinning next to us, enthused in an infectious way we hadn’t seen nearly enough of since the arrival of his newborn. “Ok guys,” I entreated, “maybe we can do it with iframes. I’ve been having a lot of fun with jQuery lately, so let me play around with it and see what I come up with.”
It was a lot of fun to see two pages race against each other! Performance testing can be rather bland—staring at waterfalls, repeating tests—but watching a competition seems to be one of those things that humans are hard-wired to enjoy, and it tickled me like Elmo to think that I could take something I’m passionate about—web performance—and make it a bit more appealing!
Don’t get me wrong, there are many good tools for web performance testing (notably, the open source webpagetest.org and showslow.com, which I will be working to integrate), but there are a few areas where I think whichloadsfaster adds some wicked weapons to the web performance warchest:
- Competition. Since it’s easy to pit pages against each other, it becomes natural to check the performance of your most (and least) favorite sites, adding to the argument that speed is a competitive advantage.
- Testing in real time, while you watch. This has a big impact factor because a “real” test holds your attention.
- Support for many browsers (IE 8/7/6, Firefox 3.0+, Chrome, Safari, most of mobile WebKit). Because of the detailed and invasive nature of performance testing, most performance tools are browser-specific. We make the tradeoff of collecting fewer events for the convenience of running the tool in every browser with no install.
- Finally, there is a sharing link that developers can send out to run on their friends’ browsers. This feature is something I hope to develop further by adding a beacon API to automatically retrieve the results (see below).
Moving forward, I would like to improve whichloadsfaster in three major areas:
- Automation of test results. The plan is to make a beacon API and a couple of example servers to collect the data (php, rails, django). This way, developers can just send out the link and sit back and see their performance results roll in across different locations and browsers. Fully automated testing would be as simple as causing a remote test machine to load the URL you want with your desired browser. This could be done with selenium or a similar library, or possibly even built into whichloadsfaster (have to work around caching issues).
- User perception testing. Since we’re right in front of the user, we can ask them which page appeared to load faster and get a better handle on that ephemeral but most important metric, time to first interaction. I’m really excited about this one!
- Integration with other tools. I plan to add a link to compare your pages on webpagetest.org using the video film strip feature, and also to test the individual pages in the waterfall tool. Since this project is about spreading the web performance gospel, I’m open to linking to any useful performance tool.
A call for help
The one problem that really bugs me is that whichloadsfaster doesn’t play well with sites that try to break out of the iframe. This includes major sites that users want to compare, like myspace, twitter and nytimes.com. It’s a terrible user experience to type in one of these and watch it unexpectedly take over the screen. I’m completely sympathetic with using framebusting to avoid clickjacking attacks, but I truly think this project is a legitimate reason to frame a site, and I want to create an excellent user experience (I mean, have you noticed the keyboard shortcuts?).
I’ve successfully tested a framebuster-buster that prevents sites from breaking out, but one of the side effects is that it also prevents outgoing links. In the end, the users should at least know what is going on and why the site can’t be compared. I’ll continue to work on this, but if you or a developer you know has expertise in this area, I would love suggestions and advice via email or the github issue.