RSS RSS feed | Atom Atom feed
Popular Articles: Tom Riddle's Magical Diary | AJAX Lego Robot | AJAX CAPTCHA | SQL Multisets

W AJAX design pattern

Reducing perceived response time

This is a new design pattern which was independently discovered by me and Will Glass over the phone one day while discussing a painful loading time of around 7 seconds for a web application we were working on.

Describing the problem

The web app front basically consists of a Google Map plus a form. The user can search for an address/place or, interactively on the map, select a boundary area for the search. When the search is submitted to the webserver, the webserver sends off an additional request to a 3rd party geodata server for the purpose of retrieving geocoding data plus demographical data. The problem is that this request to the 3rd party geocoding provider takes some time. The end result would be a wait for about 7 seconds between the time the search was submitted and the end resulting page showed up. The picture below depicts what’s going on
1. User submits a search request with HTTP POST
2. A blocking request to the geodata server is issued
4. Geodata retrieved and results are sent back to the browser
5. Data received by browser
6. Browser finished processing and rendering the data and page fully displayed.

W AJAX Solution

A way to reduce the response time is to utilize some AJAX. The idea is the following. When the search request arrives at the webserver, a new thread associated with the http session is spawned with the task to asynchronously do the 3rd party geodata request. Control is immediately returned back to the browser with no geodata. The browser, upon getting the no geocode data immediately sends of an AJAX request (asynchronous by nature) while it continues to render the web page with images, the Google Map, tables etc. This rendering takes some time to happen and by the time the rendering is done the AJAX request has landed at the webserver and is doing a blocking wait for the spawned geodata server request. When the 3rd party request is done, data is very quickly returned back to the browser (once again one of the natures of AJAX) and the rendered page is updated using DHTML. All in all reducing loading time, but more importantly reducing perceived responsiveness for the user.
The picture below with accompanying steps describes more in detail how it works.
1. User submits a search request with HTTP POST
2. A non-blocking request to the geodata server is issued in a spawned thread that is associated with the session. A web page layout with no geo data is returned to the browser.
3. Browser sends of an AJAX request with the purpose of retrieving geo data. Browser continues rendering the web page layout and elements.
4. AJAX request arrives at webserver and does a blocking wait for geo data to arrive. Geo data is finally calculated and results are sent back to the webserver. Webserver relays geo data to the AJAX request which returns.
5. Data is received by browser and presented in a quick manner using DHTML

Did it really work?

Was the rendering that bad? and is the extra complexity worth it? It depends on the situation and application. In our case we were able to squeeze down response time to around 3 seconds with the end result of a happy customer, in other words, it made a huge difference for us.

Why "W"?

The calling pattern traced out in the image above resembles a "W" and an "U", combine this with how "W" is pronounced in English and you get one visual "W" and, at least, one phonetic "U". Besides, it's arguable the best way to start a name, what do you think Will? :)
slashdot digg del.icio.us technorati [more]



Re: W AJAX design pattern

So what is it you claim to have discovered here? AJAX?

Re: W AJAX design pattern

Ha

Amely

Thank you for the information!

Re: W AJAX design pattern

Great instructions. Thank you!

Re: W AJAX design pattern

Great research! Thanks for the job you've made!

Re: W AJAX design pattern

just do an async ajax call with the first pattern

Re: W AJAX design pattern

What if the browser doesnt have access to the 3rd party server directly? In our case we were submitting regional demographic requests to esri which costs money.

Add a comment Send a TrackBack