What to think of when creating Edge Side Includes

Tags:

In my previous post I wrote about Edge Side Includes (ESI) and how ESI can have huge benefits on the server side. The trick about ESI is to be able to serve parts of a web page as fragments and then let the ESI enabled proxy include these fragments into a whole page. One natural question when dividing a page into fragments is what should go into each fragment. There is no straight answer for this question and the answer will be different with each case, but I think there are some simple rules one should keep in mind when dividing a page into fragments for ESI inclusion.

The golden rule; think reuse

ESI enabled proxies cache fragments, and a fragment can be reused on several pages if the fragment is of a nature which lets it do so. My strongest advice when it comes to using ESI is to track down parts which are common between several pages and then make sure these are divided into fragments which the ESI enabled proxy can keep as one fragment and reuse on several pages.

Illustration of common footer used on several pages

My favorite example of such a global fragment is the typical footer holding – perhaps - some legal content which should be displayed on all pages. Such a footer should be one fragment the ESI enabled proxy can cache and reuse between all pages intended to include it.

Forget the visuals

Implementation of ESI are very close to the presentation layer and many web projects have a strong connection to the visual presentation so it's only natural to try to locate ESI fragments when doing architecture of the presentation layer. In such a process design sketches can be a good tool to identify what should be the different fragments of a site. But, looking at sketches can be very blinding when it comes to the rule of thinking reuse.

One must remember that mark-up and content is what goes into the ESI cache. It is reuse of mark-up and content we want and should think of when creating ESI fragments. On a design sketch something which could be a common and reusable fragment can easily be overlooked due to differences in the visual presentation. It can be as easy as having the same content presented at two different pages but with different colors.

Example of component with different presentation trought css

The illustration above are the same "ul" list with different styling. This could be one ESI fragment. Example code of the above illustration can be seen here.

The visual presentation should be – and this should not be needed pointing out – controlled by CSS. Both CSS and JavaScript can be used to not only give a visual presentation and interaction to the pages but also help in creating reusable fragments we can benefit from in the ESI cache. I will give a couple of examples on how we can use both CSS and JavaScript to create more reusable fragments in a later blog post.

Size does matter

When slicing up a page in ESI fragments its pretty tempting to take short-cuts and just slice the page into a handful of fragments. Let's say we have a site with a header, footer, a left column and a content column.

Illustration of areas on a web page

It would be very tempting to define each of those columns as ESI fragments, but this will not give great benefit. We have to dig deeper if we want some real benefit. For example, lets say our content column consists of eight news articles which flow in a Z-shape from top to bottom as new articles are published.

Illustration of an area on a web page with small fragments

If we define the whole content column as one ESI fragment the whole column must be updated each time one of the eight articles are updated, or when a new article appears and the oldest one falls out of the flow. In other words, if one article change the whole area must be updated. This will force the application server to render the seven unchanged articles plus the one changed due to the change in one article.

It's also very little chance the whole column will be equal between several pages on our site and this will give little reuse of ESI fragments.

Illustration of esi fragments flowing

Separating each of the eight articles into separate ESI fragments increases benefit. In the case of update of one article, only that one article will need to be thrown out of the ESI cache. The rest of articles which weren't updated will not be needed to be re-rendered on the application server due to the change in one article.

It's also much more likely for one article to appear on several pages on our site so by keeping each article as one ESI fragment gives great reuse in the ESI cache. The article can appear in different types of "flows" and columns and it will still be reused by the ESI enabled proxy.

Be creative

Using Edge Side Includes can be summarized into analyzing your site carefully and break things down into reusable fragments. The more reuse the better, but be aware; there are pitfalls. I will try to cover pitfalls in a later post and how they can be overcome but keep in mind- and be prepared to think a little bit different to achieve re-usability.

16.08.2009 03:43 - Posted by Trygve - Comments: 0 - Technical

Comments:

Post a Comment:

HTML Syntax: NOT allowed