Hippo CMS' Delivery Tier has been designed from the start to scale up and out linearly. I've written blogs which explain some of the backing concepts recently. My previous blog was about measuring performance, where I showed rendering with Hippo Delivery tier is blistering fast, even without page caching enabled. How much is enough, you could ask yourself like Edward Skidelsky did regarding economic growth. Ethics regarding performance (scalability) are fortunately much easier: Performance is a self-evident good, the faster, the better.
Our customers are, justly, more and more demanding regarding performance, which is GOOD for Hippo. Since we have always focused on large content sets, separation of content and presentation, performance and scalability, it is giving us more and more an edge over competition. Since our delivery tier has been setup very modular through Spring pipelines, we can easily inject new behavior and features. For example our Targeting enterprise feature is such a module that seamlessly injects itself into the delivery tier. Since we do Targeting at application level, it plays nicely with things like Page Caching. I am a firm believer of caching, however, it must be done at the appropriate level: entire page caching by CDNs, Squid, Varnish and so forth are becoming too limiting when it comes to giving visitors a personalized experience. This is were customers can use Edge Side Includes to bridge the gap between entire HTML caching and not caching at all. The Edge Side Includes specification (2001) is obviously not a new kid on the block, but the last years I've seen, fortunately, more and more a shift from websites relying on caching proxies like Apache mod_cache, squid, varnish and so forth, to running live on the application. However, running applications live on the application introduces new challenges, like how to go about caching html snippets from external services or completely personalized snippets and at the same time being compliant to Web Content Accessibility Guidelines (for example limiting use of asynchronous ajax calls to include html snippets). We've added seamless support for creating pages containing Edge Side Includes (configurable in running production environments!) to our Delivery tier. The Delivery tier is also capable of being an ESI processor, thus actually rendering edge side includes in the HTML.
Edge Side Includes introduction
Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly. The purpose of ESI is to tackle the problem of web infrastructure scaling. It is an application of edge computing.
It is fairly common for websites to have generated content. It could be because of changing content like catalogs or forums, or because of personalization. This creates a problem for caching systems. To overcome this problem a group of companies (Akamai, Art Technology Group, BEA Systems, Circadence Corporation, Digital Island, Inc., Interwoven, Inc., Open Market, whose ESI-related technology is now owned by FatWire Software, Oracle Corporation and Vignette Corporation) developed the ESI specification and submitted it to the W3C for approval. The proposal editor was Mark Nottingham.
ESI Language Specification 1.0 was submitted to the World Wide Web Consortium (W3C) for approval in August 2001. The W3C has acknowledged receipt, but has not accepted the proposal.
ESI is implemented by some content delivery networks (CDN), such as Akamai, and by some caching proxy servers such as Varnish, Squid and Mongrel ESI, although many do not implement the complete specification. Akamai also adds additional features to the version they support.
ESI, Hippo CMS Delivery Tier and when to use them
In the blogs Hippo CMS and performance and Reproducible and falsifiable performance tests with Hippo CMS I've written about the blistering performance numbers achieved with the Delivery Tier Page Caching. If the Delivery Tier can serve 10.000+ pages per second from its page cache, then why would you ever need ESI for extra performance?
Of course, there are multiple obvious reasons, for example:
- Some parts of a page might be pointless to cache (eg 'welcome back John')
- Some parts of a page might depend on external services where you do not want your application to fail/starve if the external services are down/slow
- If you are making use of a CDN and only need some parts of the page to be rendered by the backing application
But wait, the above reasons are pretty much the same as described at Asynchronous HST components and containers . Is this not just covered by marking some components to be rendered asynchronously? Yes, that is correct and as a matter of fact, the ESI support is making using of the exact same mechanism. The only difference is that the asynchronous ESI are rendered and injected into the HTML before the final HTML is send to the browser, and with  the asynchronous parts of the HTML are fetched through ajax calls from the browser. Obviously, Web Content Accessibility Guidelines compliance can be achieved easier with ESI than with asynchronous ajax includes.
How to mark some part of the page as ESI?
With Hippo CMS Delivery Tier (HST), pages are build up from a tree (composite structure) of reusable HST Components. This tree of components is stored in the Hippo Repository, and modifiable at runtime. Webmasters typically do this through the Channel Manager. Marking a HST Component or subtree of HST Components to be asynchronous is as simple as marking the HST component with
hst:async = true
The above will result the HST component to be asynchronously rendered through a browser side ajax call. Making the HST inject an ESI include in the HTML instead, is as simple as also adding to the HST component:
hst:asyncmode = esi
Now, instead of rendering the asynchronous components with ajax calls, the HTML contains a snippet for example like
<esi:include src="http://example.org/_hn:component-rendering%7Cr1_r2/news" onerror="continue"/>
The example include above is for the URL http://example.org/news and will target a specific HST component with namespace %7Cr1_r2. Obviously, when marking a HST Component to be rendered as an ESI include, you have either some caching proxy or CDN in front of the application that supports Edge Side Includes, or, you have the Delivery Tier (HST) configured to be an ESI processor......! Yes, the HST can be configured to be an ESI processor rendering ESI includes as well.
Note that for a single page it is possible to configure asynchronous ajax components next to asynchronous ESI components.
Hippo Delivery Tier as ESI Processor
The HST can be configured to run as an ESI processor, resolving edge side includes present in the HTML. This ESI processing support plays seamlessly with the Page Cache, making the HST capable of serving pages from cache and injecting the edge side includes per request. Running the Delivery Tier as ESI processor can be done through the hst-config property:
esi.default.fragments.processing = true
ESI support is included in Hippo CMS 7.8.2 and higher.
Woonsan Ko (see Technical Leadership part) for doing all the excellent coding and writing the support for HST to be able to run as an ESI processor.