AJAX latency

Jep Castelein of backbase has written a nice summary of current thinking on AJAX applications and latency. He points out that most AJAX developers are taking the easy way out, having synchronous logic execute when the user performs an action. This causes a delay as the data is fetched from the server, which is exactly what we are trying to avoid by using AJAX!

More importantly, it causes a delay that doesn’t give the user the right cues as to what is going on. Users are used to page refreshes and the way page refreshes are rendered in the browser. Some kind of cue ALWAYS needs to be given that the application is working on your request and is not broken.
I love some of the quotes he uncovered from various blogs about latency in AJAX applications.
The form assembly writes

What happens really is that XmlHttpRequest is not used for what it is good at: asynchronous, behind-the-scene, access to the server, but in the context of a synchronous transaction by the user. Users want instant feedback from an application, and a better way to achieve that is by freeing the application from its over-reliance on the server.

Harry Fuecks puts it more bluntly: “Synchronous requests are bad”.
And a thread on the server side sums up the economics of latency quite well, at least for consumer apps:
These days, bandwidth is cheap, latency expensive.

2 thoughts on “AJAX latency

  1. Joe Berkovitz September 11, 2005 / 12:12 pm

    I agree — and this critique applies just as strongly to other RIA technologies. It’s terribly easy to use Flash, Flex, Laszlo, whatever, and wind up with a gorgeous interface that has exactly the same latency characteristics as the HTML that it replaced.
    I have a further observation: where a request involves some user-initiated change to the application state (for example, editing a shopping cart quantity), it’s not enough to merely give instant feedback of the “Loading…” variety. RIAs should optimistically apply all local edits immediately, and let the server catch up. This is tricky to do in a robust way (since it involves ensuring that the server eventually does catch up, and possibly merging server-side edits) but the effect on the user experience is startling, giving the appearance of zero latency.

  2. jon September 11, 2005 / 2:03 pm

    The problem with that approach is, of course, that if you tell the user something that isn’t true, you have to explain it after the fact!
    Taking your example, what if there’s not enough inventory for incresing the number of items in the shopping cart? If you optimistically update the UI, you are going to have to display a very awkward error message in about 5 seconds, once you realize that!
    I talked about the problem of handling error conditions in asynchronous data transfer a year or so ago. It’s a bear!
    However, as long as you figure out an error-handling strategy that isn’t confusing to users, I think you’re on exactly the right track.

Comments are closed.