Use link headers to activate http2 push
Opened this issue · 3 comments
n-ui applications used the Link
response header to indicate to browsers and the Fastly CDN that they should prioritise downloading the CSS and Javascript assets.
Page-Kit dropped this approach and instead sends resource hints in the HTML response body (as <link>
elements in the head). I think the rationale was Link headers give a negligible performance gain over <link>
elements, but headers are more complicated to maintain. The browser's parser looks ahead in the body to find resources to prioritise downloading and would discover these hints only fractionally after it reads the link header. The MDN docs imply there is little difference between the two. I doubt this change was perf tested because it would have been difficult to make a useful test a year or so ago and there wasn't an up to date agreed definition of what's "objectively better".
While the link header probably makes little difference to the browser, it is more meaningful to the Fastly CDN. Fastly does not parse or read the body. But it does read headers. It uses a link header to do an HTTP server push. Another feature of HTTP2 is header diffing and compression (via HPACK) which means only changes to headers are sent back and forth. This means it doesn't really cost anything to send these long headers and the CDN can figure out when it does and does not need to do the push.
- Is it possible to implement link headers as well as link elements?
- Could we test this outside Page Kit in a single app?
- Does it improve performance in production?
- Can we add this to Page Kit in a way that's not horribly complex? Or provide an API/helpers to let the App implement it where performance is more critical (eg front and article)?
- Is the speed bump worth it given the complexity?
Thanks @kavanagh! It's definitely worth exploring this when we pick up our Performance work later this year, especially if we can benefit from providing the headers to Fastly 👍
Is this the kind of thing that could be tested with a A/B test and spoor data to see the overall impact?
That should be possible, but can decide exactly which approach to take when we pick up the work.
As @pixelandpage says, we will be addressing the performance work (including how best to expose the performance benchmarks) later this year - in Q3.