It was only slightly ironic that various caching/compression mechanisms were highlighted again this weekend on ajaxian.com, as I was already well underway with some “improvements” of my own in this area with Tapestry.
It all started out innocently enough, first there was the fairly well known IE image caching issue to resolve. A few more links and things start really shaping up.
Nothing done was particularly new or pushing the edge, but the end result of all the (now released in the snapshot repos) new work is that anyone writing a Tapestry application can now expect to get all of this “for free” right out of the box without thinking about it:
- 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
ExpiresandIf-Modified-Sinceheaders 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.
As an added bonus - this gzip compression also appropriately only compresses content on browsers that really support it (such as disallowing IE gzip compression on anything lower than ie sp2 ) , and all ajax/json responses are compressed.
There is a lot going on under the hood (still subject to some changes/tweaks), such as intelligent gzip compression and caching of compressed content on the server to help eliminate redundant cycles that aren’t needed until content actually changes.
I don’t know if anyone has ever taken a look at my poor old rickety server hosting Tapestry demos before, but if not you should be able to see the results there. (as much as my server/bandwidth can handle at least, especially as this server is also responsible for hosting the other more well known Tacos demo.)
-
1
Pingback on Dec 4th, 2006 at 8:24 am
[...] 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. [...]
-
2
Pingback on Dec 4th, 2006 at 8:52 pm
[...] Tapestry developer Jesse Kuhnert knocked out a tasty update, tuning cache parameters and adding liberal use of gzip to yield a bundled dojo kit that is 25% of its previous size over the wire. Also, text responses from Ajax and json requests are compressed automatically. [...]
-
3
Pingback on Jun 26th, 2007 at 7:38 pm
[...] many instances) - is also now available. The details of why/how that came about can be read about here. These enhacements do all kinds of nice things for your assets for you automatically - such as [...]
Leave a Comment
Latest Entries
- updated foxylicious extension for Firefox 3
- how to fix butt ugly ubuntu hardy heron fonts
- Where are our java leader’s opinions on closures?
- Tapestry 4.1.5 Released && various Tacos project releases (like Seam / jQuery support)
- painting by numbers, or how html cowards hide behind CSS
- Rails component envy
- OGNL 2.7.2 Released
- news flash - Swing is a terrible API to emulate in web development
- hip hop is neat
- good closures, bad closures
Dec 5th, 2006 at 9:04 pm
Thanks! I’m not a formal programmer but I’ve hacked out quite a few applications. I was recently working on some caching processes… the difficult way by writing out my source page and then checking the age of the page. Your methods here may go much further!
Dec 8th, 2006 at 3:03 pm
HTTP Compression is a huge win for text/html, css, js, XML, XSL. When we started redlinenetworks -> (now juniper) we would regularly see 50% bandwidth savings on commercial sites. Then we added features to rewrite the HTTP headers on-the-fly to maximize browser caching and things sped up even more.
Things get complicated for the browser based on content-type, cache settings and SSL/vs. nonSSL. Even compression type (gzip vs. deflate) is an issue as is page content (iframes, etc.) If you have lots of traffic and want to make sure your site works with all kinds of compression, it’s worth your while to go with an appliance like the Juniper DX. I don’t work there anymore, but it was the best box on the market for HTTP/S compression and general site acceleration. We would always be able to beat the rendering bugs when other boxes erred out.
If you don’t feel like spending a bunch of money on a commercial solution, of course there are free alternatives like mod_gzip. There are several tricky parts that can bite you though, so my advice here is to be less optimized but always working.
- Throroughly test your content on IE 6, 7 and FF. text/html is usually safe to compress, while js and css are trickier with client caching so be extra careful. XSL is usually ok, XML is iffy. Double check everything in SSL if you use it. For example IE 6 can’t support compression of XML with no caching via SSL.
- Test with cache cleared and a dirty browser cache
- Use deflate (vs. gzip) if you can, especially if your solution uses chunking vs. content-length.
- Chunking reduces Time to First Byte significantly, so use that if you can. Otherwise try to compress and cache the response. Most free solutions are pretty slow (high latency) at compression, so try to avoid latency wherever you can.
- add headers “Vary: Accept-Encoding, User-Agent” so that downstream caches don’t cache the wrong thing for the wrong browser
- Use Max-Age: to avoid the 304.
We’re using lots of compression and caching techniques on an AJAX / XML / XSL ecommerce site at http://www.cocoluna.com.
Here are our current stats:
Content Av. Object size %bytes saved
HTML 780 bytes 26%
CSS 7.7K 74%
JS 19.7K 68%
XML 3.4K 76%
XSL 10.5K 35%
The site is all SSL, so you can’t sniff the network to look at the requests but you can use browser based tools. Feel free to contact me if you want more info or specific tips.