You are here

Optmize your Luminis page loads with smaller images, GZip, Browser Cache control and minified Javascript/CSS

Submitted by mwinstone on Tue, 04/29/2008 - 16:45

Here at the University of Ottawa, we did some calculations on the footprint of our Luminis page loads and we noticed that our average page load was just around 683KB with an empty cache (we've added a lot of new images, JavaScript and styles to Luminis). We did some calculations and we figured out that with an average of 4 page loads per minute under our max load of 10 000 concurrent users, we'd be pumping out just over 20GB of data per minute on the University network. Sufficed to say that scared us a little.

However, with a few tweaks here and there we were able to drop our average load to just around 250KB (that number should shrink even further with a few other tricks I have up my sleeve ;-) Here's what we did.

(Just a side note, I'd recommend installing Firebug in Firefox and then adding YSlow as well. A great way to measure just how much of a difference these changes are making)

1) Optimize your PNG files

If you don't need a full 32 bit PNG image, don't use a 32 bit PNG image, use a 24 bit image. In fact, with simple images, sometimes you can even drop down to an 8 bit PNG. You can use the latest version of Paint.NET or Photoshop's "Save for Web" feature to save your images in the smallest format possible. In Paint.NET, just click on "Save As..." and select the PNG type that generates the smallest image file size without compromising image quality. Photoshop's "Save for Web" gives you more control over this (but costs a lot more than free ;-)

2) Image Maps or Sprite Sheets

This was mentioned at the Sungard Summit during a presentation (I can't remember which University it was, if you're reading this please add a comment below to properly give yourselves credit for a great idea). Basically, concatenate as many of your smaller (and sometimes larger images) into single files and use the "background-position" CSS property to set which part of the image to display. This minimizes the number of HTTP requests sent in and out. Each HTTP request contains some extra data about the request which takes up space within the packets of data. If you make one request instead of five, then you don't send that extra info over and over again. It's only a few dozen to a few hundred bytes per request but it can add up pretty quickly.

3) GZip

This was a tricky one to pull off. When I contacted Sungard about this, they said flat out that GZip wasn't supported with Luminis. So keep that in mind when doing this, Sungard won't be helping you out if you run into problems. Also, if you run your portal behind a reverse proxy, GZip data has been known to have issues with that type of setup. So keep that in mind as well.

For those still reading, here's what you do. (I've copied and pasted from our wiki, keep in mind that your directories may or may not be on the D: drive, or not even on windows for that matter, but you should be able to figure it out)

Add the "jspbook.jar" file found on to


I don't know why it needs to be in both, but I was getting intermittent errors if it was in only the tomcat-cp directory. Just add it to both, doesn't really hurt anything.

Look for this web.xml file in


Change the "web.xml" file to include the following just above the section for the mime types

(See Appendix 1, couldn't get the browser to render the XML properly)

You can change those patterns as you like but that worked out best for us. Remember, don't GZip images or PDF files. They're already compressed and doing so can cause problems with rendering or reading the file data.

DO NOT DUPLICATE URL PATTERNS IN WEB.XML FILES this will double compress files and the browser will display gibberish

Restart your tomcat server and you're good to go. You can test your results using YSlow (an add-on for the Firebug add-on for Firefox)

4) Cache Control

Yet another jar file addition and filter setting. This time, I've included the compiled JAR file (since only the source code was available online and it took me about 30 minutes to get Eclipse to compile it properly). You'll have to rename the file to a .jar since Lumdev won't let me upload a .jar file. Remember, don't extract the ZIP, just rename to .JAR

Here's where I got the source from

Add the "cachefilter.jar" file to both


(Same reason as before for having to install in both directories)

To "web.xml" found in


and add the following code

(See Appendix 2, couldn't get the browser to render the XML properly)

Now I highly recommend that you tailor the cache settings to your specific setup. This is set on a Dev server which is strictly for testing the page load optimizations I've been doing. In production, I would imagine that our JavaScript files wouldn't be cached as long as the images and css files. So feel free to play around.

5) Minify JavaScript/CSS

Found this website ( and ran all my CSS and JavaScript through it. I got an average savings of around 30% per file. Most of the time the "Powerful Compress" didn't work (javascript and/or CSS failed to be interpreted properly by the browser) but I found that the difference between basic and powerful was around only 3 or 4% per file. So you aren't losing much by sticking with the Basic minification.

BE SURE TO KEEP A COPY OF THE ORIGINAL JAVASCRIPT AND CSS FILES. They'll become unreadable after doing this so keep another folder somewhere with your originals and/or development files.

Well that's about all I've got for today, feel free to add to the list of optimizations in the comments. Hope this helps out a few of you out there.


Mathew Winstone
Web Analyst
University of Ottawa




Luminis Version:



This is very cool, I put the gzip and cache filters onto our test box and it seems to be working great so far.

I did a little searching and found that Yahoo has a YUI Compressor that is a java jar file you can download and run from the command line. That makes it scriptable, so if you wanted to compress all the CSS and JS files from a script, you could do it.

I've tried this, and it seems to be working. However, my CSS files and my JS files are not being gzipped.

I have a feeling that this is because of where I'm serving them from. Could you tell me where CSS and JS files need to be in order to be gzipped?

The problem seems to have been Firefox's cache. The js and css pages were loading from cache.

I've cleared the cache and now things are working as expected.

Thanks - sorry about that. D'oh!

I can't get it to work on a development box even after clearing firefox's cache. Could this have anything to do with parallel deployment? We are running Luminis on Solaris 10 does anyone know if we need to install anything in order to get this to work?

Thank you!

Vladimir Mollov

There was a setting on the load balancer which caused requests from browsers to be stripped out of the Accept-Encoding item in the header. Figured it out and it works now. I still can't get some custom js files to compress but the concept is working.

Thank you!

Vladimir Mollov

Mathew, good post! Plymouth State University has been using sprites in our portal since our Luminis IV go-live and it does wonders to load times and I did discuss it in my presentation at Summit this year.

If anyone wants more information on sprites (a.k.a. Image Concatenation), I've got an article on my blog regarding the topic:

Did anyone get the cache control working in Luminis 3?

I tried adding the <filter> and <filter-mapping> elements in to web-apps.xml (which is where Sun says to put it for iPlanet 6.0), but that didn't work for me.


The problem might be that the iPlanet web server is not delivering the content via a servlet but directly - try the following to get it via a servlet - you may additionally need to add a servlet to deliver the files !

In addition to the filter lines in web.xml - for Luminis 3 (iPlanet Web Server - not tomcat) only try:

NameTrans fn=”assign-name” name=”servlet” from=”/cp/myarea/site”

This should be the 2nd line in the

block, after “NameTrans ..stats-xml” and before those that force handler by extension. rich

Well thanks for the idea, but I'm afraid it's a little worse than I explained.

Whenever I put the filter elements in web.xml or web-apps.xml, the web server will not start at all. :) So, looks like this is a no-go. That's fine, I've just decided to move all of our static content off over to a meda server, and control the caching there.


I've implemented your gzip and cache filters on our test and production server, and while it's working fine, it's also caused tomcat's catalina.out file to grow positively huge (over 1GB currently). The file is full of lines that look like this:

GZIP supported, compressing.
GZIP supported, compressing.
GZIP supported, compressing.

Is there a way to tell these filters to shut up? :)

I don't know. We've only been using in Dev so I'm guessing we haven't had enough activity to notice that. We're going live with our QA environment with a few hundred people soon enough so I'll keep an eye out and see what we can do.

Mathew Winstone
Web Analyst
University of Ottawa
Luminis IV.1.1