About WebWait and Caching

I received today a question often asked about WebWait, so I’ll answer it here for reference.

WebWait User asks:

I have been using webwait for a while and have a quick question for you. When running multiple calls on the same website, is each call downloading the entire page again, or is the information being loaded from the browser cache?

My answer:

It will do whatever the browser would do if the page was loaded normally, so that would usually mean the 2nd-Nth time it will download from the cache. To counter-act that, you can simply disable your browser cache while performing your tests. Or if you do want to test cache performance, just open your site once (either in the browser or WebWait) and then start the WebWait tests, obviously keeping the cache enabled throughout.

WebWait Upgrade: Deletion, Quick Entry of Multiple Sites

I made a couple of upgrades to WebWait this week.

First, you can now delete entries. This is useful for curating a set of results, since you can save a result set for others to try out, or for later analysis and comparison. If I get requests, I may also allow users to re-order the results for that reason too. You can only delete a trial when it is complete, i.e. when all calls to it have been made. This is not ideal, but would require significant rework. Again, I’ll respond to feedback on this one.

Second, you can now enter multiple URLs in the input field, separating them by space. I received a request from a Dzmitry Markovich, who wanted to time hundreds of websites at once, and figured I should support it. It’s an undocumented feature intended for advanced users, as I don’t have time to think about how to integrate it into the UI without compromising the simplicity of the design (e.g. with a text area; I should at least mention the feature in the FAQ, which is now ancient.) In the case of someone wanting to enter dozens or hundreds of websites, they need to cut-and-paste into the input field.

Funnily enough, both of these features had previously existed, but were removed when I overhauled the architecture to make way for the benchmark saving feature. The new architecture, being based on semantic events, made the deletion feature rather easy. The multiple-URL feature was also quite straightforward, as it would be with any architecture.

This is the latest of four updates in WebWait’s lifetime of as many years. Slowly but surely :).

WebWait Updated

One of the projects I wanted to work on in my time off was WebWait.

It finally does what I wanted it to do all along: Permanently record benchmarks. You can get a unique URL for each benchmarking session you run by hitting Save. Funny – WebWait was running as a Rails app for several years, but was always a pure browser-side client until I finally completed this. (Ultimately, I didn’t use Rails anyway – see below.)

Some other enhancements too …

  • Bar charts (using the Google Charts API):

  • Expanded dashboard, showing a box for each site you’ve trialled. (Previously, there was only one box ever shown, the latest one. Since people like taking screenshots of these, I figured it would be cool to include multiple boxes.)

  • There is also a JSON view of the trials that were recorded.

It would be cool to expand it further, for example allowing pages to be cross-linked when they benchmark the same trial. But I’ll leave it here and see where demand takes it.

The new WebWait server is powered by the incredibly productive trio of Ruby, Sinatra, and TokyoCabinet. On the browser, it’s still jQuery, with the DataTables plugin and my own jQuery iFrame plugin. Hosted on SliceHost (where I have now happily migrated many things.)

WebWait Two Point Oh

I’m pleased to announce a major upgrade to WebWait, the first big upgrade since I launched the site 2.5 years ago. It’s based on watching how people are using it, talking about it, and sending me direct feedback about it. Thanks to all who have provided feedback.

The new features are:

  • Multiple sites You can keep typing in new URLs and hitting “Add”. This will put them in a queue of sites to eventually be benchmarked. (I decided against a big textarea where you could type in all URLs at once; this would be confusing to the majority of WebWait users, who are casual visitors wanting to check out the time for their own site.)
  • Stats Average, median, and standard deviation for each website, in a summary table. Indeed, the summary table is the cultural centre for all these new features – when you queue up a site, it’s immediately added to the table.
  • Export The export feature seems to be popular in List Of Tweets. I took the same UI concept and applied it here, so you can export data in plain text, HTML, and CSV format. The CSV is especially interesting as one of the people who’ve given me feedback is a statistician who’s planning to run analysis on some data.
  • Call Data View times for each individual call.
  • Expand/Collapse Call Data You can choose whether to show call data or not. Collapsing call data gives you a neat overview of stats for each domain.
  • Delete You can delete individual call data, or delete an entire website record. This is useful for outlier data; for example, you can see how fast the site loads from your browser cache, by turning browser cache on and deleting just the first call in the sequence.
  • Stats Average, median, and standard deviation for each website.
  • Browser compatibility. WebWait didn’t work upon launch in Safari, but it does now work in recent versions of Safari (I think a change in 3.0 made it work again :)), and works fine in Chrome too. This is important for users testing how their website loads in different browsers.

Thanks for reading. As always, let us know what you think of the site and anything else you’d like to see.

Table with expanded results:

Table with collapsed results:

Export results data (text):

Export results data (HTML):

Export results data (CSV):

WebWait in the Wild

I haven’t blogged about WebWait since launching it almost two years ago. But it’s been quietly growing into quite a pretty well known site among certain communities in various languages. What I like seeing is people are actually getting value from it…it’s not just a novelty, but a tool for them. Here are some examples.

A conversation about blog timings … and soup recipes:

At December 7, 2008 6:24 PM, Blogger Arfi Binsted said… I love clear soup like this. Kalyn, for some reason, almost 2 months, my browser goes so slowly when I come to your blog. I am not sure where it comes from. Today, I try to open it from the link on my blogroll, it works! Just as well it is a click away from a miracle just to happen for Barbara 🙂 hugs. At December 7, 2008 6:41 PM, Blogger Kalyn said… Maris, this is one of the best parts of blogging in my opinion. Arfi, thanks for telling me. I don’t know what’s going on because I use Webwait.com and check and my blog always seems fine there. I’m going to remember to check back with you and see if it is still a problem. I do hope you’re right that it’s a good omen!

A softly, softly, twitter encouragement for the TechCrunch boys:

liking http://webwait.com/ – http://fav.or.it took 3.04s – (pretty quick!) – @techcrunch took 13s!! – sort it out boys

A tech journalist compares browser speeds:

I used WebWait.com to test how quickly Chrome 0.2, Firefox 3, Safari 3.1, and Internet Explorer 7 loaded the InformationWeek.com home page. The results for three page loads averaged were: Firefox (5.21s) Safari (6.34s), Chrome (6.48s), Internet Explorer (8.90s).

A reviewer notes how much caching helps and I discover in the process I can almost grok Italian geek-speak:

La seconda volta grazie alla cache WebWait ci ha messo 5.17. Un tempo discreto direi.

A blogger produces a “webwait research report” – schweet!:

Ko nih, tanya sket pun tak boleh. Oklaa aku tunggu ko buat positioning tuh. Sambil2 tu jom buat research… :: WebWait Research Report :: Site: farisfakri.com: Average load time after 15 runs: 0.11s telescopictext.com: Average load time after 15 runs: 0.12s google.com: Average load time after 15 runs: 1.11s Blog: ladycoder.com: Average load time after 15 runs: 5.29s blog.farisfakri.com: Average load time after 15 runs: 8.12s soleh.net: Average load time after 15 runs: 9.02s noktahhitam.com: Average load time after 15 runs: 10.07s life4hire.berceloteh.com: Average load time after 15 runs: 11.99s kujie2.com: Average load time after 15 runs: 14.10s berceloteh.com: Average load time after 15 runs: 14.52s Terima kasih Yam, kerana memberi aku kerja. Laporan kajian aku mendapati feedjit, nuffnang, mybloglog, dsb adalah antara yang menjadi punca utama kelembapan loading sesebuah blog. (MM – Google Translate says “Thank Yam, because I gave work. I found the study report feedjit, nuffnang, blogspot, etc. are among the main source of humidity loading a blog.”)

WebWait is just one way to get an impression of speed, as the FAQ explains. And in cases like those above, it can give people a handy snapshot without relying on any browser-specific plugins.

People also love screencapping their webwait results, as this google images search illustrates. It would be nice to somehow make a gallery of those. Anyway, I’ve got some time off coming up, and one of my projects will be to make some long-overdue updates to the site, while ensuring it stays dead simple to use.

Time Your Website with WebWait.com

Update (2 days later): The site’s been popular – 10k+ views yesterday. Hit Delicious Popular and somehow got caught up in the German blogosphere, the greatest source of hits. Technorati it. There’s a good discussion in Ajaxian of the strengths and weaknesses of this technique. As with AjaxPatterns, which also reached Delicious Popular, it failed to attract Digg users somehow. (Digg was supposedly inspired by Delicious Popular. Incidentally, Digg doesn’t let you submit URLs with fragment identifiers such as http://webwait.com#digg.com, which rules out any Ajax site attempting to allow bookmarks.) Go figure. Or better, go Digg :).

Here’s another new website – WebWait. 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 is an improper simulation and 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. 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.

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.