August 28th, 2008 by
Stefan Fußenegger |
Published in
Wicket
This entry is part of my “Wicket Interface Speed-Up” series.
Now that I spent some time on configuring client-side caching and resource versioning for aggressive caching, I am going to finalize this series with an article on merging of resources and some code that you can easily use right away to speed-up your own applications in minutes.
Read the rest of this entry »
August 20th, 2008 by
Stefan Fußenegger |
Published in
Wicket
This entry is part of my “Wicket Interface Speed-Up” series.
In my last post, I explained how to change (i.e. increase) the time a client should cache resources like JavaScript and CSS files served by a Wicket application. In this post, I’ll show you how to cache resources for a year. Caching for a year is close enough to forever and a recommendation by W3C:
“To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.”
Read the rest of this entry »
August 15th, 2008 by
Stefan Fußenegger |
Published in
Wicket
This entry is part of my “Wicket Interface Speed-Up” series.
Let’s start with a short introduction before we talk about setting Expires and Cache-Control HTTP-Headers:
By default, all WebResources are cacheable for one hour, which is defined by WebResource.getCacheDuration():
Read the rest of this entry »
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.
Read the rest of this entry »
