Loading ...
close

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

ESI vs Ajax client side assembly

Posted by on February 27th, 2015

We get the request periodically to support (ESI) Edge Side Includes.   We took a deep dive with ESI and decided against supporting it.  I thought a bit of elaboration might help folks looking at options for scaling sites that need user personalization.

ESI allows you to slot in content at the Edge device, by including tags in the html code, that the edge server interprets, requests, and “includes” in the content.  You can take a web page that is mostly common content and cache all the common components.  Then at the point users make the request you can have unique or user specific data assembled at the edge and delivered to the browser.

At first glance it seems like a clever solution.  We think it makes no sense for two reasons. First your simply moving the problem of page assembly from the origin environment to the edge.  Any edge device is going to have finite processing power and the overhead of assembling pages kills performance.  The  whole point of edge devices is to be lightning fast.  The second is that its a generally proprietary technology whose origin is in the architecture of a single network.

A fair bit of what ESI offers, is in the ESI language because customers of a large un-named CDN “with litigious tendencies” cannot configure the edge proxies any other way than “in-band”. While this is perfectly sensible for a specific business model, it is of little relevance in a aiScaler context, where the content-provider is in control of the servers.

The industry has a better smarter solution and that is replacing ESI –  with Ajax; client side page assembly. We feel ESI has a short shelf life and at present is a strategic dead end.

“With Dynamic Caching you can provide all ESI functionality, using Ajax and client side page assembly. The key benefit is that using Ajax calls to assemble content at the browser moves the page assembly to the client.”

We continue to watch the specification as it evolves but have not committed to the coding until we see the more open market accepted solution, such as Ajax; client side assimilation, which we do support.

With Dynamic Caching you can provide all ESI functionality, using Ajax; client side page assembly. The key benefit is that using Ajax calls to assemble content at the browser moves the page assembly to the client.  Clients have two huge advantages.  First, dedicated bandwidth.  There is no contention at the client with a million other requests as you have at an edge server.  The second is that the processing power is local.  There are a few exceptions with devices that do not support Ajax in the mobile world.  We address these specifically in the mobile aiScaler product.

Developers who build their applications with Ajax based client side assembly get the best of both worlds.  They get the capability for nearly unlimited scale using dynamic caching technology and they get client specific customization that does not inhibit performance.

As browser technology gets better we believe the future of web technology will be smarter and smarter clients capable of dynamic communication with the server side and edge environments.

We are focusing aiScaler to support developers in deploying this technology quickly and easily to provide fast, stable, rich web applications customized to the user.

Comments (1)

  • Posted by Leif Henrikson on March 5th, 2011

    A couple of points:

    1) The primary reason for not implementing ESI would, in my humble opinion, be cost and complexity. Getting ESI right is actually really hard. You didn’t mention it – but you should consider it.

    2) ESI done right, doesn’t impact performance significantly. I know – we’ve done benchmarks. It all depends on how well thought out the implementation is. ESI can be parsed at fetch-fime and a backend fetch is always a dead slow operation – so running through the document looking for ESI tags will not have a _measurable_ impact. Memory banwidth, which would be the limiting factor is usually over 10GByte/s today and unless you’re fetching gigabits you have lots to spare.

    Besides, you will only ESI-process a small fraction of your content. Putting stuff together is just concatenating memory chunks and that is lightning fast.

    3) Saying client side assembly is smarter isn’t always true. In web programming, relying on the client side to do something, to get stuff right, is dangerous. You might have noticed have many broken links to stuff like twitter are showing up these days.

Leave Comment

US (208) 948-9786‬   EU ‭+31 621302365