Http/2 push, preload and esi


Hi there,

After reading the HTTP/2 server push documentation, I have couple of questions related to different variations of options that it supports.
First of all the relation of push mechanism and preload. What does ‘rel=preload’ do when used together with http/2 push? Or it only does anything when received by browser that doesn’t support HTTP/2?

Second question is what would give better performance, inline ESI script/style or HTTP/2 push?
At first glance it seems that ESI (inline script) should always be faster, but that’s if we only thinking about render time, but when considering increased bandwidth, the fact that Fastly won’t start responding until all ESI’s are resolved, and possibility of client-side caching, I’m not sure anymore.

Did anyone do any benchmark about it?



one of the reasons using Link headers with rel=preload as the mechanism to trigger push in intermediaries has caused some confusion is just this: it already had a meaning to the browser and now we’ve overloaded it with this other function.

To answer your first question, although it depends on the specific browser implementation, when the client sees rel=preload the browser’s preload engine is invoked and the preloading of the indicated asset(s) should start. This is true regardless of whether the asset was pushed or not. On the way to the network, the request will hit the push cache. If you’ve pushed that resource, it’ll either already be in there or it’ll be on its way, and the request should never leave the push cache and hit the wire. So, theoretically, the two mechanisms should work OK together. Still, we provide the option for you to either leave the Link header in there after you push or rip it out. I’d recommend trying the permutations out to see if you see any differences with your users. You can read more about it in a blog post we had about this - in case you haven’t already seen it:

A couple of points about your second question regarding ESI. First, our edge caches don’t wait until all ESIs are resolved before sending the full response to the client. As the data becomes available, it’s sent to the client via chunked encoding. So, it’s just a matter of where the include statements are in your page. If we have continuous bytes to send, we’ll send them, even as ESI fragments are being fetched from the origin. Second, if you inline resources (through ESI or otherwise), you get the same RTT benefit of h2 push, but you lose browser-side caching for those resources since they’re now part of the html object. That’s one of the big non-RTT advantages of push: you can distinctly cache the pushed assets in the browser cache, like you do with anything else. You can cache the pushed assets with a different max-age than the page they’re inlined in.

As always, what’s best depends on your use cases and the way your users interact with your pages. So, hopefully all the options are there for you to try it out and see what works best for you.