In this week's episode of Two Minute Tech Tuesdays, we're looking at parallel ESI (Edge Side Includes).
What are Edge Side Includes?
Imagine the following website composition with a header, a footer, navigation and a main page.
This is very common. But what if the header contains user information that is highly personalized? Well, that would mean the entire page would become uncacheable. And that is not acceptable. Luckily, people have found ways to circumvent these limitations by loading uncacheable content through separate HTTP requests, while maintaining the cacheability of the rest of the page.
There's many technologies to do that, but today we'll be focusing on edge side includes or ESI includes, as we tend to call them, ESI includes are placeholder tags that are emitted by the origin application and that are interpreted and parsed by Varnish, or similar technology that operates on the edge.
<esi:include src=” /header” />
The “source” (src) attribute refers to an HTTP endpoint that is loaded as an HTTP subrequest. Varnish will cache the responses of each subrequest separately and stitch them back together as a composition of content blocks. Each block has its own state and its own TTL. ESI parsing can be triggered by enabling:
set beresp.do_esi = true;
In terms of implementation, it could be triggered when a specific URL is matched, when the content type is assumed to be text-based content, or more intricately via a surrogate control header containing ESI that might be sent by the origin application.
sub vcl_backend_fetch { set bereq.http.Surrogate-Capability = "key=ESI/1.0"; }
sub vcl_backend_response {
if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
unset beresp.http.Surrogate-Control;
set beresp.do_esi = true;
}
}
This means the header would be loaded through an ESP subrequest, but it's also possible that the navigation and the footer are also loaded through ESP subrequests.
And that brings us to the subject of parallel, or serial, ESI processing. In Varnish Cache, the open source project, each ESI subrequest is handled sequentially, which means head of line blocking could take place.
Assuming that every ESI subrequests takes one second, the total loading time would be over three seconds. In Varnish Enterprise, ESI subrequests are handled in parallel:
Even though each subrequest might take the same amount of time, the total loading time will amount to little over a second. And that explains ESI, and more specifically, parallel ESI. Please remember that this is a native Varnish Enterprise feature that doesn't need to be installed, configured or enabled.