You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 👍
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.
The text was updated successfully, but these errors were encountered: