Using AJAX in Portal

Client side aggregation using AJAX interactions seems to be a must have these days.  Everyone wants to be like iGoogle or pick your favorite client side aggregated site.  Now while this is wonderful for portal, it is not always appropriate to use and can severely impact performance.  For example, here is a high level typical lifecycle for a portal page that has 5 portlets on it without AJAX:

1. User requests portal page
2. Portal receives the page and determines the user has access to the 5 portlets on the page.
3. Portal calls each of the portlets (this can be synchronous or using parallel rendering depending on portal and portlet settings.)
4. Each portlet returns html markup to portal.
5. Portal combines the entire markup and returns a single HTML page to the user.
6. The user’s browser gets the HTML and requests all the client side assets such as JavaScript and images

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Now, here is the scenario where client side aggregation (Ajax) is used to render the portal page:

1. User requests portal page.
2. Portal receives the page and determines the user has access to the 5 portlets on the page.
3. Portal calls each of the portlets (this can be synchronous or using parallel rendering depending on portal and portlet settings.)
4. Each portlet returns html markup to portal.  This markup is really some basic markup and JavaScript that will trigger an Ajax call back to the portlet once the page loads.
5. Portal combines the entire markup and returns a single HTML page to the user.
6. The user’s browser gets the HTML and requests all the client side assets such as JavaScript and images.
7. The user’s browser now executes the JavaScript to make the Ajax calls for each portlet.   Keep in mind that each of these calls requires an HTTP connection to the server that takes at least 100 milliseconds.
8. Each portlet creates its HTML markup and returns it to the browser.
9. The browser now executes JavaScript to render the HTML.

Now, these extra steps might not sound like much when using AJAX because after all if a portlet takes a long time to render, it is of course much better to render asynchronously instead of holding up rendering of the entire page; however, not all portlets are this complex.  Let’s take a scenario of a basic portlet that renders some customer support information and this information is retrieved from a database and is the same for all users and changes at most once an hour.  Additionally, suppose this information can be retrieved in and the portlet can be returned in 200 milliseconds.  The correct way to implement this would be to not use AJAX and to enable markup caching and set the cache timeout to perhaps 15 minutes.  So, now the first user takes a performance hit of 1/5th of a second for the portlet to render the markup but since the markup is now in cache, the next 999 users have the portlet render in less than 20 milliseconds. What happens if you use AJAX and still enable caching?  Well, perhaps that user gets their portlet in 20 milliseconds since no markup is returned; however, now an AJAX call must be made which incurs a hit of at least 100 milliseconds to simply establish the HTTP connection, then the portlet requires 200 milliseconds to fetch the data, then client side JavaScript is executed to render the returned markup.  So for this scenario, the rendering time is actually not only slower for the first user, but every single user of those 1000 has to go through the same 300+ ms process before they see their information.  Add up the total rendering time for all users in all scenarios and in the first scenario and it comes to less than 2 total seconds of rendering time.  In the second scenario, there are over 100 seconds of rendering time and delays to process HTTP requests.

This scenario above is a simple scenario where it is black and white as to not use AJAX, but there are often gray areas as to whether AJAX is appropriate.  Here are some general usage guidelines:

1.  Use AJAX when it is highly likely that a user is going to interact with a portlet on a page.  This will save page refreshes and create a better user experience.
2.  Use AJAX when a portlet takes a long time (> 1 second) to render.
3.  Use AJAX when it is possible that a portlet might not be entirely reliable or response times are unknown.  This will prevent the entire portal from hanging if that one portlet does.
4.  Do not use AJAX when displaying information that is common to all (or a group) of users where most of the users do not actively interact with the information.  This will prevent you from caching.
5. Do not use AJAX when a portlet renders quickly.  The delay due to the additional HTTP request will slow down the page rendering.
6. Do not use AJAX for very infrequent user interactions.  This often requires additional markup to be delivered to the client and it slows down the page for all users.