Optimizing Portal 7 Page Builder Theme for performance

Saw this in my in-box this morning: -

How does the theme influence the performance of the Portal site?

The theme influences both the server side and client side performance. Whenever a Portal page is rendered the theme is included on the server. The theme defines the layout and structure of the site – including various static files like javascript, pictures, css, and others. It also triggers the rendering of portlets, widgets or other content. Depending if the theme is a client side or server side theme the requests that are sent after the initial rendering of the Portal in the browser also differ – a server side theme will trigger full server side rendering requests including the theme again with each request while the client side theme would trigger a larger number of small dynamic requests that will update the layout to the newly selected page and its portlet content.

When trying to optimize the performance of the theme one needs to think about both about the time spent on the server as well as the time on the client side. On the server side it is all about execution of code on the server that can take up processing power and memory. This can be analyzed with profiling tools like the Java Health Center or Jprof or … Also the number of requests influences the server side response - if an excessive amount of requests is sent it will slow down the server.

On the client side the performance of the site is determined by the rendering of the returned markup. The markup links to static resources. The static resources can contain javascript, pictures, css, and others. Time is not only spent for the download of those resources but also in the interpretation of the loaded javascript and css. The more complex the css and javascript is the more time is spent in the browser for parsing and execution.

Tools like Firebug or Development Console from other browsers typically allow to determine how much time is spent on the download as well as the rendering of the resources.

My recommendation is to check the time spent for the loading of the page and then optimize the slowest parts. If the main Portal request (typically to .../wps/myportal/... unless you changed the context root) is taking too long you would need to check what is slow on the server side. Most of the other resources being rendering are referenced by the theme or the portlets on the page.

This article does not cover basic tuning tips like ensuring that compression is enabled on the web or proxy server and that the correct cache headers are being set for static resources to prevent subsequent downloads of static resources. Both tunings have a large impact on the theme performance and should be enabled. Please see the Portal tuning guide for more information on those topics:

IBM WebSphere Portal V 7.0 Performance Tuning Guide

and thought …. hmmm, that's VERY relevant to a project on which I'm currently engaged, so will (a) bookmark this for future reference and (b) make sure that my Application Architect colleague sees it.

The article is in the WebSphere Portal Wiki here.

This also ties up with the point that Mark Polly had made a few weeks back about Fixpack 7.0.0.2 doing some nice things for Portal theme performance …...