Ajax Girl

Jesse Kuhnert, Tapestry/Dojo team member, spent time on caching and compression mechanisms in the effort to give the best experience “for free” with Tapestry.

The result was:

• Browser Caching: Previous versions of the framework weren’t aggressive enough in the way that all of the bundled assets (images/javascript/css/etc) were managed with http headers. Though the Expires and If-Modified-Since headers were being used it wasn’t really the complete solution. All of these resources now have realistic / appropriate headers set depending on the type of content and browser being delivered to. (Etag / Cache-Control / Expires / etc) Things will probably still be undergoing more and more change as this section is refined but anyone currently serving this content from the core Tapestry jars (or their own) - with no other configuration - should see a significant performance boost with the added caching support.
• Gzip Compression: The biggest (and scariest) change has been the addition of intelligently gzip’ing content where appropriate. Now all javascript/css/html content that is typically managed by Tapestry gets a good once over with some gzip compression to help make those responses as snappy as possible.
• Much Faster load time: The overall load time for pages should be much better now. The bundled version of dojo with tapestry is now served at a size of roughly 50k - down from the default size of 200k.

I would love to see some benchmarks on the gzip compression side. I used to read that for smallish file sizes, and certain machines, and certain networks, the overhead wasn’t worth it.

Have anyone in the community done good work on when to gzip versus when not too?

Source: Ajaxian
Original Article: http://ajaxian.com/archives/compression-caching-for-faster-load-times