Australian Banks - Frontend Performance Comparison

Recently, I did a quick Homepage frontend performance test of eight well known Australian Banks and it does look like they do not follow the frontend performance golden rules.

NOTE:
Due to confidentiality and competition among banks:

• I am not using there real names, instead I am using dummy name for these banks(Bank1, Bank2… Bank8).
• Also no further details are provided as to what could be improved by each bank but instead a generic summary.

The finds are summarized as below.

Test details (as at 31/01/11)
Test Location: Sydney
Browser: IE 7
Connection: DSL (1.5Mbps)
 

• Except for Bank3 and Bank5, all the banks had HTML download response time less than 20%. Therefore most of the time (80-90%) is spend on downloading non HTML content. For Bank3 primed cache scenario there were two requests made to the server, one for HTML page and other for a gif file. For Bank5 primed cache scenario there were three requests made to the server. First one is the HTML page and other two are a Text/Plain and a JS

• All the websites have keep-alive enabled. That is good.
• Except for Bank5, all the websites do not cache static content.
• All of the websites fail to use a CDN. This might not be a big issue; however, if they want to expand outside Australia and become more global, CDN will help to achieve fast response time
• If we assume that CDN criterion is not an important factor, at the moment, then Bank5 to a certain extend is following the Front-end Performance Golden Rules. It could do even better by compressing Images and JS/CSS files.
• If we assume that CDN criterion is not an important factor, at the moment, then Bank2 and Bank6 websites perform poor in regards to Front-end Performance Golden Rules compared to other websites.
• Except for Bank7, rest of the websites do an average to a poor job in compressing JS/CSS files. Some of these files could be reduced by 40%-45%.
• Five out of eight websites don’t even GZIP their text (HTML). Some of these websites could reduce the text by 20%-30% by just GZIPPing the text.

LoadRunner - lr_vuser_status_message function

There are situations during load testing when you want to find out which data(i.e. username) was consumed by a VUser(For example, Few VUser were having errors). If you don't have proper logging turned on(or a code) during load testing, it can be a pain. One way of getting data information is to use lr_vuser_status_message function.

From LR Help "The lr_vuser_status_message function sends a string to the Status area of the Controller. It also sends this string to the Vuser log. When run from VuGen, the message is sent to output.txt"

For example, In the error log(Controller) you can find out which VUser had an error and using lr_vuser_status_message function you can then find out what data that VUser was using. This way it helps save time in debugging any data related issues.

Following example shows how to use lr_vuser_status_message function.


In the code above, UserName parameter string is passed into the lr_vuser_status_message function.

Now during load testing if you open VUser window in controller, following is what you will see.


From the image above you can notice the UserName(Status column) that each VUser is using in current iteration.

Now if you have an error in the error log, find out which VUser had the error and open up VUser window to find out what data that Vuser was using. It won't tell you what caused the error but will give you enough information to start investigating.