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: https://www.fastly.com/blog/optimizing-http2-server-push-fastly.
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.