My colleague Martin Ridgway recently posted on how your web site’s performance is important to the user experience. Of course this is true for WebSphere Portal sites as well, so I wanted to steal…er, leverage his recommendations and elaborate with some specifics on how we see those implemented within WebSphere Portal sites.
Before I go into some specifics, let me emphasize the need for disciplined testing when changing these settings. First, test the system as-is. Use tools such as HttpWatch, YSlow, Firebug, etc to examine headers and how many resources are being requested. Make one change at a time and retest. You should also consider creating a versioning strategy for your CSS and JavaScript files that will work in conjunction with your caching strategy.
Minify text files
The same applies for Portal sites. However, you usually don’t want the minified versions for your Dev environments. So consider performing the minify (and optionally obfuscate) actions in your build scripts. You do have build scripts and a CI environment (Jenkins, Bamboo, etc), don’t you?
Gzip all the things!
If you’re using Apache as your web server, this is relatively easy to accomplish using mod_deflate. You can deflate/gzip JavaScript or CSS based on file extension, but that won’t work for all of the HTML pages generated by portal because they don’t have extensions. You’ll have to catch and compress those based on their MIME type: text/html.
If you’re looking at tacking this process one step at a time, I would prioritize gzipping over minifying, at least in a Portal environment. And we often see HTTP servers that are very underutilized, so adding some compression to the response path will not likely cause a problem. Monitor your web server hardware/VMs and web server performance to be sure.
Concatenate, concatenate, concatenate
There is a lot going on in the construction of a typical Portal page, so minimizing the number of HTTP requests can be tedious. One thing you’ll notice quickly is the number of Dojo resources that are downloaded for each page request. These can be optimized though.
Using CSS sprites within a Portal theme is an easy way to trim a handful (or sometimes tens) or calls, depending on who chopped up your comp into HTML/CSS. If you have a web developer handy, have them help you with this. If you don’t, then you can find online CSS sprite generators that can help you take care of some of the problem.
Browsers have a cache. Use it!
The full range of caching options you have available from WebSphere Portal is beyond this post, but you can easily use the mod_expires and mod_headers Apache directives to set the cache durations in the response headers, and you can control this based on mime type or URI (LocationMatch directive).
Perceived performance is as important as real performance
It’s often not possible in a Portal site to move all of the JavaScript to the end of the page. Try to do this for any JavaScript that is site-wide and stored in the theme, but any custom JavaScript that appears in portlet applications will be loaded in-line based on where it falls within the page.
Living on the edge
Responsive web design is relatively new, and even newer in WebSphere Portal sites. There is an article on developerWorks that will help you implement RWD based on the default Portal theme.
In conclusion
What Martin said. Seriously, his recommendations apply to all types of web sites, regardless of the underlying technology. Then use some of these tips and the very thorough WebSphere Portal Tuning Guide to continue to make your site perform as quickly as possible for your users.
