In the last few weeks we’ve worked with several customers who all experienced similar issues with their site under load: users were reporting that data they entered in to form fields was “disappearing” and that they were being asked to re-enter it a second time.

While no two websites are exactly the same, we were surprised to see that in each of these cases the same root issue was to blame. Specifically, these sites all used advanced AJAX techniques to make parts of a form dynamically change based on the values selected by the user earlier in the form.

Consider this simplified example from a hypothetical airline booking website:

The form has been designed to show all cities and airports that the airline services in both the departure and arrival drop-downs. However, once either an arrival or departure has been selected, the other drop down is modified to only show valid cities.

For example, if selecting “San Jose (SJC)” from the departure field, the arrival field would lose the “San Francisco (SFO)” and “Oakland (OAK)” options because the airline doesn’t do flights between those cities.

The idea behind this behavior is to simplify the user experience. But depending on how the form fields are updating and how your website scales, the user experience could actually be very poor. Here’s how that can happen…

AJAX and User Behavior Timeline Conflicts

Suppose that the departure <select> box has an onchange JavaScript event handler, which in turn makes an AJAX call with the selected city/airport. The resulting response is a bunch of <option> tags that are meant to replace the body of the arrival <select> box, as illustrated here:

This process works based on the assumption that the AJAX call will return so quickly the user could not possibly begin selecting the arrival city before the AJAX call completes. This is the normal behavior and it works just fine.

But now imagine that under heavy load the AJAX request starts taking longer and longer to return. Now the timeline looks like this:

What is happening now is that the user is actually working faster than the backend AJAX call. Now the user is able to make a selection to the arrival city and then after the selection was made the select box contents get replaced, eliminating the selection (for our web savvy readers, this is most frequently caused when the AJAX response gets assigned to the select element’s innerHTML field).

Under this scenario, the user did select a value but then the value appears to be “deselected” some time later. It doesn’t even take a very long AJAX call for this behavior to happen – a couple of seconds is enough time for some users to make selections.

Lessons Learned

So what are the lessons learned here and what can we do to prevent this type of behavior? The most important thing to understand is that when doing performance and load testing with today’s modern web applications, simply knowing how long HTTP requests take to complete won’t necessarily tell you how the end user’s experience is under such load.

It’s also important to know what those HTTP requests tie to and how they affect the user interface and the associated user interaction. This is sometimes difficult to do, since not even the web developers may think of these types of edge cases, but it’s worth thinking about.

The easiest way to test for this situation is to actually test from the end-user’s experience. Rather than doing traditional load testing, which simply simulates HTTP traffic, use a service like BrowserMob to run a load test that uses real web browsers. These will exercise the full AJAX logic inside the browser and will catch things like this.

For example, one of our customers who had a very similar issue reported seeing errors in their load test that claimed a field wasn’t filled out – just like a user would if they didn’t notice that the form field selection they made was erased before they submitted the form.

Simple UI Solution

Finally, the best thing to do always do is to tune the system so these AJAX calls don’t slow down. But you can never guarantee that the performance will always beat a user’s speed when selecting forms, so it’s good practice to include some additional UI logic to prevent this from happening. There are two common techniques you can use to solve this exact problem, though similar techniques can apply for similar problems:

• When the onchange event fires off an AJAX call that you know will change other form fields, de-activate those form fields before making the AJAX call. This will ensure that the user can’t set the value in between the request and response.
• Instead of blindly filling the select box with the contents of the AJAX response (via innerHTML), use a more granular technique, such as JSON, and iterate over each option in the select box – adding and removing fields as necessary.

In either case, it’s also a good idea to have some visual indicator that background work is happening. None of these solutions compensate for a high performance UI framework, but they are good practices regardless of your UI performance and can avoid these types of tricky load-related UI bugs.

Tweet This Post 

No tags