Wicket Interface Speed-Up
August 15th, 2008 by Stefan Fußenegger | Published in Wicket
After reading Matt Raible’s thoughts on [OSCON 2008] Even Faster Web Sites by Steve Souders I decided to look into the topic myself. I knew that one bigger project built with Wicket was reported to be slow. However, I always made the mistake to look into server-side performance as client-side performance never was an obvious problem – well, estimating client-side performance on my Quadcore/4G RAM/Ubuntu workstation with broadband connection admittedly wasn’t very representative 
According to Souders, “80-90% of the end-user response time is spent on the frontend”. This obviously makes potential performance improvements of (quite insane) 20% on the server a drop in a bucket. Therefore, I decided to make interface performance tuning a top priority in my work queue and looked thoroughly into it.
I used Yahoo’s YSlow for Firebug to get a first impression on the performance of our biggest Wicket-based project. The results were as bad as suspected: YSlow honored my carelessness in interface response time with less than 50 points or grade F (even without ads and Google Analytics) on most of the pages. Without even knowing about them, I taunted 3 of 13 Rules that are encapsulated in the YSlow plugin:
- Make fewer HTTP requests
- Add an Expires header
- Gzip components
In the upcoming series “Wicket Interface Speed-Up”, I’ll explain how I tuned Wicket, made peace with YSlow and finally went for at least a B on most of my pages (without ads and google-analytics). Well, not only a B but also considerably faster page loading and rendering.
Wicket Interface Speeding:
- Modifying Expires and Cache-Control Headers
- Caching Resources Forever
- Merging Resources for Fewer HTTP Requests
UPDATE: There is an ongoing discussion on my “Wicket Interface Speed-Up” on Wicket’s mailing list.
