Skip to main content

Digital Transformation

12 Things You Shouldn’t Do on a Portal Project: #10 When Web 2.0 is 2.Much

Ajax is a good thing, right?    Well, not always.

What Happened

A financial company had a content based intranet and the implementer decided that absolutely everything should be done using Ajax.   The home page had about a dozen portlets on it.  Some were personalized but most simply displayed non personalized content which did not change often, perhaps  hourly at best.  Some content even changed less than once a day.  The fundamental problem with this approach is that an Ajax request incurs at least a 1/10 of a second overhead in simply establishing an HTTP connection.  Given that a browser typically can only handle 4 simultaneous HTTP requests, all these request fire off synchronously, plus they also incur an heavy load on client side processing.  As a result of all this, page load times were about 15 seconds in single user scenarios.  Under load, page load times rose to over 30 seconds.

 

What Should Have Happened

Any portlet which simply serves content should never be implemented with Ajax.  This is especially true if the content is shared across multiple users and can be cached.  Cached portlet content can be retrieved in milliseconds where retrieving the same content (even if cached) with an Ajax based approach will take over 1/10th of a second.  If you multiply this times the number of portlets on your page times the number of page hits, it is easy to see the magnitude of extended wait time Ajax introduces into the portal.  After converting a majority of the portlets on this customer’s home page to not use Ajax, the page load times were reduced to less than 4 seconds under load.  The figure below shows the typical lifecycle for an Ajax call on a portal page.

WebSphere Portal Ajax Lifecycle

Ajax of course is extremely powerful and can create great user experiences; however, it must be used in appropriate situations.  Here are a few guidelines for when using Ajax is appropriate in portal.

  • A portlet will take longer than a second to render
  • The content of the portlet is not common between users
    • Portlet takes longer than a second to render
  • Content may change often and is minimally cacheable
  • A portlet will likely be interacted with
    • In place refreshes save entire page refreshes
    • Better user experience
    • Better performance
  • When a portlet connects to a system which may be unreliable
    • Prevents portal from hanging if system fails
    • Lets user interact with remainder of portal

One other word of advice about Ajax.  When web pages are assembled vial client side aggregation, the information which is rendered with Ajax typically cannot be indexed by search engine crawlers such as Google.  So, if you have a public site and you want it searchable, it is imperative to evaluate how Ajax is used.

Previous Installments

  1. Where’s My Homepage?!?
  2. The Business Asked for It
  3. Methodology for Methodology’s Sake
  4. The Never Ending Strategy
  5. I Built It But Now I Can’t Support It
  6. We Can Get Big ROI From a Portal
  7. Is Best of Breed Always Best?
  8. When Developers Can’t Develop
  9. When Not to Use a Portal

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Glenn Kline

Area Vice President, Custom Development and Mobile Solutions

More from this Author

Follow Us