Tag Archives: jsf

Optimizing Richfaces AJAX a4j update1

This is one of those things you have to laugh or cry about.

The primary reason that I have found that our consolidated AJAX page is slow, and that no amount of HTTP traffic optimization is going to fix, is that two of our composited components had implemented getters by way of a database query.

This is absolute bad practice – JSF does not guarantee that your getters will be called just once, so even in a Web 1.0 application you may be making redundant database queries.

In an AJAX application this problem is exacerbated – doubtless none of those queries are necessary on the AJAX request.

In our application each of those queries ate up about 100ms, multiplied about 3 times each because they were embedded in getters. Obviously this soon becomes a noticeable delay ruins the feel of the application.

Simply caching the query in the bean removes this problem, but in a Seam component you have several more options to refine this approach.

Since our beans were EVENT scoped, we specifically outjected PAGE scoped variables to host the cache.

Optimizing Richfaces AJAX a4j

Just a quick post because there doesn’t seem to be much on the web about this.

RichFaces AJAX library, originally a separate project called Ajax4JSF, is a well integrated engine for AJAX-enabling a JSF web page.

The library adapts standard JSF/HTML forms so that the POST is sent back to the server via a background request (e.g. XmlHttpRequest ). All requests handled by the server are wrapped in a filter that runs what is mostly the normal JSF lifecycle. The response is then processed by the filter to encode aspects of the JSF response that are not in the returned HTML – like HTTP redirects. This post-processed response is returned to the client which then parses the response and applies it to the page, updating elements, triggering redirects, and so on.

This is fast because JSF builds and holds an in-memory representation of the web page through out the page lifecycle, so the original JSF page does not need to be re-parsed.

Never-the-less, there’s always a need for more speed, and as you expand your AJAX enabled page to include more and more dynamic controls, you may encounter some slow down as both the server and the client need to parse more and more data.

In our application, and on a single page, we have 20 externally included sections, each with a couple of independent forms, and a corresponding number of modal panels, again each with their own forms. Since these forms have been independently developed, performance issues have arisen.

Luckily the designers of the AJAX enabled components within Richfaces have kept this in mind and have provided a full set of attributes that allow you to control what is included in the AJAX lifecycle. Unfortunately, the documentation is somewhat sparse on the various core attributes and how they interact so I hope to use this page to detail how these tags can be used together to optimize the AJAX JSF lifecycle. It’s a work in progress that I will populate as a I update our application.

Core Lifecycle Tags


Behaviour Tag Applies to Performance impact
Establish an AJAX form a4j:form JSF page When any AJAX event defined within an a4j:form is submitted – only form fields from within that form will be submitted. This is the only way to limit the data sent to the server.
Restrict server-side processing a4j:region JSF page Isolate a section of the component tree so that during the AJAX request the server only has to process a subset of the page. Attributes on this tag identify how that isolation affects the individual JSF phases – including determining what is to be included in the HTTP AJAX response. selfRendered appears to disregard non-verbatim code, but it may work well with Facelets since it already stores HTML in the component tree.
Identify a dynamic output region a4j:outputPanel JSF page The outputPanel marks a place in the component tree for which the server might send a response, and thus for which the client may have to perform a partial page update. Setting the ajaxRendered=true attribute on this tag bloats all AJAX request from the page and thus slows client and server processing.


In the next post I will follow up with information about the attributes on these tags. Several attributes on the above tags interact with each other; for example what is the effect of combining a form inside an a4j:region renderRegionOnly=”true” and a4j:outputPanel ajaxRendered=”true”?