Building an AJAX Application: Design pattern and strategy - Cached HTML

Introduction

  In early days, web publish was static and simple: browsers fetched static html files from servers,
  displayed them, cached them and never fetched them again. The web world was changed after
  "dynamic" publish kicked in: we didn't cache pages any more. Just like enjoying vegetable and fruit, 
  we mostly got "fresh" pages from server containing the same static content again and again. 
  The result is that we suddently face heavy server load and much more bandwidth requirement. 
  
  Can we go back to the simple life: load once and never load again? The answer is Yes.
  
  Let's take a look at major pages on most popular commercial web site such as ebay.com and
  amazon.com. You may notice that a big percentage of content are "static" such as header area, 
  navigation area and footer. This static content is sent over and over during a single visit or across visits because 
  it is published dynamically and browser can not cache them. To verify, just download a free HttpWatch to see how those 
  jsp and php are sent back for every page load. 
  
  
Solution
  
  The strategy of "Cached HTML" is to build these pages as static html pages and mark them as "never expired"(as fresh). 
  A fresh representation will be available instantly from the cache.
  
  Then use Javascript (AJAX) to dynamically load the dynamic content. 
  
  In this way, browser doesn't even send any validation request for the container file that consists of static content to 
  the server (no 304).  The static html pages simply always load these pages locally. And the Javascript resideing in the
  static content is launched to fetch the dynamic content.
  
 
 
Demo
   
Here is an ordinary dynamic published page
       
   The popup screen is a screen sampled from EBay.com where the blue rectangle is the area containing
   dynamic data. In the popup screen from the link above, both static and dynamic data in page are 
   dynamically put together at the server side and then sent back.  Here is request summary from HttpWatchShow details:
        
        
        
        Show details
        
        
        
   As you can see in the summary, the page, ebay.jsp, is never cached. Size of transfered data is about 71k. Remember: it also 
   costs server time to put them together.
       
   
Here is an "static" page with client-side include for dynamic content
       
   The difference in this approach from the one above is that only the area within the blue rectangle is loaded from server 
   while the rest of the content in the page is loaded from local cached (I assumed that only the blue rectangle area contains 
   dynamic data).
       
   The popup screen is the same screen sampled from EBay.com where the blue rectangle is the area containing
   dynamic data. In the popup screen from the link above, the static data (outside of the blue rectangle) resides
   in the static html file, ebay.htm, while the content in the blue rectangle is fetched from the server while/after 
   the static page is loaded. Here is request summary from HttpWatchShow details:
        
        
        
        Show details
        
        
        
   As you can see in the summary, the page, ebay.jsp, is never cached. Size of transfered data is about 0k. 
   It spends some time (0.146s vs 1.437s on ebay.jsp) to fetch the content in the blue rectangle, d2.jsp (7k byte vs 71k on ebay.jsp),

   You may not see a lot of performance improvement here (since local access depends on disk load/speed, local cup load/speed 
   and so on) but there should be a lot on scalability.
        
   Here is an "static" page with client-side include for dynamic content and its request summary
        
   You may want to download the FREE HttpWatch and measure it yourself. (Instructions to measure Show details)
        
        
         - make sure your browser allow cache
         - download HttpWatch and install it.
         - load this page with IE and click at the HttpWatch icon at the toolbar of IE to open the HttpWatch subframe
           as the lower part of your screen. 
         - click at the record button to turn it on
         - visit the ebay screen (either an ordinary dynamic published page or an "static" page with client-side include for dynamic content) once.
         - Don't use the refresh button of IE. Instead, close IE and reopen it.
         - right before you nevigate to the target page (either an ordinary dynamic published page or an "static" page with client-side include for dynamic content),
           click at the clear button to clear the HttpWatch log
         - now click at (either an ordinary dynamic published page or an "static" page with client-side include for dynamic content)
    
 
 
 
Conclusion
   
  
   For those pages with a lot of static content mixing with dynamic data, this approach could save huge amount of bandwidth and server cup time.
   Using HttpWatch to watch web pages, you will see most time browsers spend on server is to load dynamic content like 
   jsp and php while files containing image and script are cached. Remote Scripting provides a "second chance" to load dynamic 
   into static. One of the drawback of this approach is that it is not easy to update the static files with renaming since the files are containers.
   You may also want to see an opposite solution of mine at  

      Building an AJAX Application: Design pattern and strategy - Client Side Include

   It is easier to update the static content in that approach.