Monday, January 28th, 2008

A Study of Ajax Performance Issues

Category: Ajax, Articles

Coach Wei, of Nexaweb and Apache, has published a study of Ajax performance issues in browsers, and they won’t surprise you:

Obviously, we would like to see browser vendors take a serious look into the following issues and put them on their roadmap:

  1. In all major browsers, performance with Array and HTML DOM needs improvement in general.
  2. Browsers need to provide API support for Computed Box Model and Style;
  3. FireFox needs to improve performance of “eval”, object creation and “in” operation
  4. Internet Explorer needs to improve performance in general to be at least on par with other browsers. Beyond that, “String” manipulation on IE needs continued improvements;
  5. Safari: “pop” operation performance needs improvement
  6. Just-in-time (JIT) compiler: This maybe a bigger task than an incremental fix of some existing features, however, it is worthy of every penny. JIT will not only fix the String manipulation issue, it will enable JavaScript to truly shine in matching the performance of native applications. The amount of client side logic (aka, JavaScript code) needs to grow in order to accommodate the growth of application complexity, for which JavaScript runtime performance problem can be a major bottleneck.

Read the study to get the details on each item. It includes the results such as the DOM operation performance information:

Ajax Performance Study

Posted by Dion Almaer at 5:18 am

3 rating from 42 votes


Comments feed TrackBack URI

Why does the word Ajax have to be in here?

It all comes down to Javascript doesn’t it?

Comment by SchizoDuckie — January 28, 2008

Haha, indeed

Comment by Daniel — January 28, 2008

By itself it dosnt have anything to do with Ajax but these operations results is based on methods often used after reciving ajax request response. So i guess the title can be accepted now its about the Ajax performance issued.

Comment by Ronni Rasmussen — January 28, 2008

Why isn’t Opera included in this little Test? Because it was to fast to be measured?

Comment by Zsolt — January 28, 2008

While it’s very interesting to see how browsers natively perform, I’d be even more interested in seeing how AJAX Libraries such Prototype and JQuery possibly help us get better performance through their convenience methods for DOM manipulation and accessing. I don’t do as much native browser-level DOM manipulation as I now often leverage the libraries for this.

Perhaps someone representing the libraries can take this existing table/grid and add their convenience methods and metrics for comparative purposes, and comment on how they may help people avoid the cross-browser performance pitfalls?

Comment by Dov Katz — January 28, 2008

>>Why isn’t Opera included in this little Test?
The similar list
with addition of Opera
and the list for
oncoming versions of browsers

Comment by Maxim Kozhukh — January 28, 2008

Ajax is becoming the word that represents general DHTML programming these days. So calling it “Ajax performance” is fine.

Comment by Mark Arrington — January 28, 2008

>> FireFox needs to improve performance of “eval”
eval is much faster in FF 3

Comment by Les — January 28, 2008

Two points: referring to “all major browsers” but not including Safari or Opera seems to be misleading.

The second point: getElementsByTagName does *not* return an Array it returns a NodeList. The difference? NodeList is a dynamically updated list that always reflect the current state of the dom — or at least it should, i’m not sure what the JS implementations do.

Comment by olliej — January 30, 2008

Ah ingore the first point — i see that the original article does at least cover safari — although the absence of opera is somewhat poor.

Comment by olliej — January 30, 2008

Yes “all major browsers” but not including Safari or Opera is misleading.

Comment by Aphrodisiac — August 15, 2008

Leave a comment

You must be logged in to post a comment.