January 07, 2006

The Importance Of Browser Caching Mechanisms and Its Relationship To XML Data and Transformations

One of the single most overlooked benefits that comes along with using Browser-based XSLT for client-side rendering of XML data is the fact once a transformation file and/or non-changing XML data file has been cached by the client browser, if upon subsequent requests, a finely-tuned and/or modern-day browser (of which any modern version of IE, Mozilla-based, Safari/Konqueror, and Opera -- not a complete list, but this covers the MAJOR majority market owners -- qualify) which conforms to the HTTP specification discovers that a local cached copy of the file exists and is unchanged (using various ways to determine this, usually a conditional HTTP GET request will look for a return response code of 304 which means 'Not Modified'. The same general idea can be accomplished using the HTTP HEAD request. For details of HTTP Status Code definitions see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) this will result in the browser using the local cached copy instead of the packet-based data stream from a new, non-conditional GET request.

With this simple knowledge some amazing things can be achieved in the browser-based applications domain. It also nicely showcases just how important client-side XSLT processing plays in increasing overall application performance while decreasing overall application cost (in terms of server processing and bandwidth costs.)

Can it get any better?

Yep!

In fact, you can find some advanced methods of taking advantage of browser-based caching mechanisms in the Browser-based application development title form O'Reilly that Kurt and I are presently working to finish up. :D

Worth noting is the fact that the same is true with CSS, a fundamental piece of advanced browser-based application development in terms of user-interface presentation and (in browsers that support the latest versions of CSS) light XML display processing (ordering, positioning, show/hide XML content, etc...) While its more than likely taken for granted, the simple difference that comes by importing a CSS file, and including the CSS inline can mean the difference of a high-perfomance browser-based application and a slllooooowwwww as molasses browser-based performance sucking blackhole from Hell.

Enjoy your Browser-based XSLT-enhanced Day!

---
Please note: This site is a BAAAAAAAAAADDDDDDDDDDDDD example of this in terms of CSS as it has been my playground over the last year+ for client-side XSLT and CSS experimentations and is in desperate need of being properly cleaned-up. In-line and included CSS is fine for hacking as is can be easier to update the code from within the same file. But in terms of production is a BIG PHAT NO-NO! :) (note: various CSS hacks require the use of inline CSS to overcome browser limitations. More on this topic is found in the O'Reilly title as well :)