Browser app in high latency/low bandwidth environments

Question

We have a typical business application with an Outlook-looking Winforms client talking to asmx webservices. We’d like to make a portion of the features available over our intranet, but the new users we need to reach - all of them - are in developing countries with dial up-type bandwidth and a lot of latency. And they all use IE 6.

So we need keep the number of round trips as well as the amount of data transferred to an absolute minimum. We’re thinking of a site with a single url, with all interaction with our existing backend via AJAX calls. Basically a thick client that keeps a lot of state, and only occasionally makes an http request to modify or acquire data. The typical web application that issues two dozen requests for each user click won’t work for us.

Does this approach sound sensible? If you were faced with this kind of problem, which javascript frameworks or libraries would you recommend? We prototyped with TIBCO GI but the XML manipulation was painful and we couldn’t get the performance in the browser that we need. Next we might look at YUI, possibly having our existing asmx’s serve JSON.

Appreciate any suggestions.

Answer 1

A couple of things that I could think of

Round trips

Like in your saying, the less the better, in order to best fit the browser client, it is best to design the interface by the use cases from the browser application, return ready-to-use data for the interface without other overhead. It would be a bit different from what you currently offer for the desktop application since the state is not as easy as thick client could have.

Transport

Enable the compression on the web server.

API

Utilize REST api where you can since some static data could be cached by the broswer and the size is smaller than put the serialized form of request in the body

Encoding

JSON is much better than XML for browser application, and the size is smaller than XML as well.

Framework

You also can take a look at JQuery or prototype The recent GWT is also great for building weblication with AJAX, it translates the java code into javascript with internationalization features etc. It also makes debugging so much easier.

For the web service, it is worth to take another look at WCF RESTful service, you should be able to utilze existing business logic while moving on the framework to WCF.

Answer 2

It's going to be all about reducing round trips, as CodeMelt said. Here's a few more ways:

Be sure that your first page load has as much information on it as it can. Too often when first building an app, the page will immediately request some more state from the server with an Ajax call. It may be that your first requests to the server can be avoided by including the information on the page.

If you have many graphics, look into using css sprites to cut down on the round trips to get the images.

Denormalize. The logical way to build the app may be to have a few different Ajax calls to get different state from the server. Combine them to return a larger JSON structure.

Use YSlow and Firebug to see what your page is really doing.

Answer 3

Here are some ideas:

• If MSIE supports it, use some way of putting static (non-changing) files into a single archive file - Mozilla supports the use of a .jar file for this purpose.
• If you can't put all your resources into a .jar or similar, preload them using Javascript if that helps.
• Ensure that static files have appropriate Last-modified: and Expires: headers for client-side caching. Make sure that "no-cache" headers etc, don't appear on static resources.
• If you're using XHR requests to get information with the GET method (which is a good idea), ensure that THOSE requests have appropriate Last-modified: and Expires: headers - AJAX requests can be served from the client cache too.
• If you are using HTTPS in particular, enable HTTP keepalives and use a long timeout - this will use up more resources on the server, but fewer on the client to establish connections and do HTTPS handshakes
• Don't use HTTPS unless you need to.