Web Performance, Inc. recently published "Using AJAX to Improve the Bandwidth Performance of Web Applications" to show the results AJAX had on bandwidth for a web application. Considering that some uses of AJAX might seem to increase bandwidth usage, this might be an interesting challenge. They attempted to reduce the bandwidth by 50% as a goal.

The goal was exceeded, reducing the application's total bandwidth by 61% with some minor refactoring of the application and <100 lines of javascript.

The report shows the javascript being used, as well as showing the actual savings and discussing techniques of how bandwidth was being saved.

It's possible that the pages could have been reduced even further with more tuning: the first request was actually larger than the non-AJAX solution, with page updates being far smaller. What techniques would you use to save bandwidth with AJAX?

I would say, before you get the actual data from the server, its better to check the content's last modified date. If the stale data's modified time is same as the one in server then return 304 status else return teh actual data. This way the Data will only be sent to the client, if its fresher than the one client already has. I have implemented this algorith in my current project.

yes optimizing webapps with Javascript saves bandwidth sometimes...used judiciously.

Ajax specifically has nothing to do with that. In fact, the way Ajax is being used typically is ruining the ability for some apps to work at dial up bandwidth speeds. Not to mention screwing up client side portability between browsers.

If you think Ajax is cool fine, but bandwidth is not one of its strengths.

If anything it tempts the developer to ruin bandwidth with dynamic slop.

If you really want to minimize bandwidth, use JSON instead of XML. Much more compact with the same functionality of an XML based AJAX approach.

You can dramatically reduce XML's readibility overhead by adding a compression filter (e.g., mod_gzip) to your web server. You have to carefully configure it based on browser identification, as some (especially older) browsers claim to accept this but don't, especially when SSL, CSS or JS are in the mix.

For browsers that do support GZip correctly, the transfer size should approach that of JSON while maintaining the versatile usefulness of XML.

Even the removing white spaces can help. Especially for JSP pages. See for example
http://www.servletsuite.com/servlets/trimflt.htm

Traffic is an important thing, but isn't the most important motivation for migration to AJAX. The thing is today web applications have to solve more complex problems and they become much less usable.
AJAX (properly used) makes users life better, because it allows getting job done much faster, and I thing it's the main problem AJAX targetting.

Maxim Wirt
http://itodo.mawisoft.com

If you really want to minimize bandwidth, use JSON instead of XML. Much more compact with the same functionality of an XML based AJAX approach.

wow, call me ignorant, but how can one compare JSON and XML..I mean does it support Xpath? Xslt? Please explain...

If you compress xml (what most servers and clients support these days), JSON size doesn't matter so much anymore..

-m.j.milicevic
http://www.backbase.com

If you really want to minimize bandwidth, use JSON instead of XML. Much more compact with the same functionality of an XML based AJAX approach.

wow, call me ignorant, but how can one compare JSON and XML..I mean does it support Xpath? Xslt? Please explain...If you compress xml (what most servers and clients support these days), JSON size doesn't matter so much anymore..-m.j.milicevichttp://www.backbase.com

Actually, I think they make a great comparison within the context of Ajax. With JSON, you don't need XPath, and in Javascript Templates - http://www.trimpath.com/project/wiki/JavaScriptTemplates - you have a much more compact, easy to use templating solution. Yes, you can use the gzip filter to compress your XML payloads, but the same filter can also be used to compress JSON, so JSON will always win that battle. Furthermore, with JSON, you can send multidimention arrays and easily access data using compact Javascript expressions.

Don

I also like JSON -- JSON-RPC-Java to be exact -- because it is RPC based. A nice side-effect is that it's smaller.

There's been a bunch of stuff written about AJAX's impact on performance but what I haven't seen yet are discussions around reliability, particularly in the presence of unreliable internet connections (does anyone here remember the days of dial up and Trumpet Winsock? That's the level of "reliability" I'm thinking of. ;-)

Does anyone know of any studies / whitepapers / what-have-you in this area?

To put this in perspective I was recently on vacation in a developing country and decided to use an internet cafe (which had broadband) to check my email. What I found was that Gmail (Web 2.0) was completely unusable whereas my corporate webmail (Web 1.0) was usable (although I did find myself hitting the refresh and back buttons a lot more than usual).

Is AJAX predicated on having a reliable network at all times?

There's been a bunch of stuff written about AJAX's impact on performance but what I haven't seen yet are discussions around reliability, particularly in the presence of unreliable internet connections (does anyone here remember the days of dial up and Trumpet Winsock? That's the level of "reliability" I'm thinking of.

AJAX is as "reliable" as a normal web application. If your internet connection fails, you won't be able to retrieve data, not matter how the response is generated (HTML, XML, JSON).

This does mean that an AJAX application needs to pay attention proper error-handling if a response fails, but this is a better than the "no server response" or "page not found" errors you would get with a standard web app.

Many people have this misperception that all AJAX application have to constantly communicate with the server, like Google auto-completion. In many cases, AJAX would make a round-trip to the server as frequently as your standard web application would: whenever it needs to save or refresh data.

Granted, this might mean more server load because the applications is more performant, and the users are able to work more quickly, but this is a *good* thing. Your overall scalability should be improved, not harmed.

AJAX is as "reliable" as a normal web application. If your internet connection fails, you won't be able to retrieve data, not matter how the response is generated (HTML, XML, JSON).

Recall that "traditional" web applications tend to encode all of the state necessary to regenerate a page in the URL, so the user always has the option of hitting the refresh (or back) buttons if something goes awry. This means that these applications are, by default, more reliable than AJAX application (AJAX calls update the browser state "invisibly") - the user always has the power to retry a request if it failed.

So to restate my question slightly - is there any information out there on how to make AJAX applications tolerant of unreliable network connectivity?

PS. I'm not talking about the extreme case of complete network failure. I'm talking about the "in-between" cases where the network exhibits variable availability, performance, etc.

AJAX is as "reliable" as a normal web application. If your internet connection fails, you won't be able to retrieve data, not matter how the response is generated (HTML, XML, JSON).

Recall that "traditional" web applications tend to encode all of the state necessary to regenerate a page in the URL, so the user always has the option of hitting the refresh (or back) buttons if something goes awry.

Sticking state information into URL has nothing to ability to regenerate a page unless session expires, which is unlikely to happen even on worst connections.

This means that these applications are, by default, more reliable than AJAX application (AJAX calls update the browser state "invisibly") - the user always has the power to retry a request if it failed.

This means that some [older] Ajax applications are nothing but junk. They do not save state on the server while accumulating UI changes on a page. Obviously, when a user hits Reload, there is nothing to display but original data. A proper application stores its full state on server, so reloading a whole page does not cause havoc, the page is simply shown using current (up to date and valid) application state.

Considering GMail remark by another poster: I think that GMail actually works better on bad connections than regular webmail because it updates only small portions instead of reloading a whole page. It does it timely and it handles response errors, so if update did not work it tries again. Of course, for GMail to work, the bad connection must be able to deliver initial chunk of Javascript. This is the only catch :)

---
Michael Jouravlev
JSP Controls: Create page components with JSP

Is AJAX predicated on having a reliable network at all times?

Not necessarily. AJAX is just another HTTP connection. IF a non-AJAX application submits ot the server and the connection is unavailable, the browser reports an error that your webapp has no control over. If XmlHttpRequest has a connection problem, the connection is reported to the callback which can handle it in a manner specific to your web-app. Imagine for example prompting the user "The server is unavailable. Would you like to save you work to your local machine and try again later?" and then save the data in the form in the page to a cookie or XML file. I would say that AJAX allows you to have better failure recovery opportunities.

I do agree that JSON will ease the client side development. But when i did a proof of concept using JSON, it fails in one situation where we need to parse the xml file available in the server using XML parsers(Java or C#) to convert them to data holders in Java or C# objects. Since JSON needs Java or C# objects to be sent to the client side. So far evry thing looks fine. But the time required to load and parse the XML file is time consiming than being sent to the client as an raw XML files itself, where this XML file can be parsed using JavaScript easily.

This is a discussion of the bandwidth on the client side. Definitely if you have big changes then the client will be better off with incremental updates. On the other hand, it would be interesting to see the effect on the cpu utilization on the server side. The more packets arrive, the greater the cpu utilization. On the other hand if a page is very large then updating less than 1500 (or the mtu on the network whatever that is) will also cpu utilization because it's not as many packets. I think often a page can a few tens of kilobytes.

Guglielmo

Try out the Fastest Known Total-Ordering Protocol

Check out the first pure-Java terminal driver

If you use AJAX properly, it will improve user experience and reduce CPU load on server too. My personal experience told me, if you try to everything in AJAX, there is no difference than you do everything in pure server side, it is just an plan dumb idea; use AJAX where you think that it is appropriate, but do not abuse it.

Regards

Hi,
I'm testing Echo2 Web Framework and I must admit that the bandwidth consumed much lower than a classical Web Application where HTTP-GET/POST and HTML contents is sent between sides.

Thanks to the Echo2 builtin ajax style feature.

Very cool framework!

bye,
Luca Garulli
Pro-Netics.com (member of Orixo.com, the XML business alliance)
OrienTechnologies.com (All in one JDO solution)