Open noamr opened 2 years ago
/cc @kenjibaheux
This makes sense. I think it may be interesting (at a later point) to also add a header to control the viewport, such as the one proposed a few years back. That would enable such hints to actually be early ones.
Yeah I think that makes sense that user agents respect these attributes. I haven't examined how difficult it would be to support them in Chrome though.
those links become un-early (they're treated as regular link headers, processed upon document initialization).
The RFC says that we shouldn't treat any headers in Early Hints as headers on the final response so I guess we shouldn't do this.
/cc @yutakahirano
Yeah I think that makes sense that user agents respect these attributes. I haven't examined how difficult it would be to support them in Chrome though.
those links become un-early (they're treated as regular link headers, processed upon document initialization).
The RFC says that we shouldn't treat any headers in Early Hints as headers on the final response so I guess we shouldn't do this.
The RFC says: Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed
. In this case, this is indeed a performance optimization (preload/preconnect etc). And the idea is that when you use the media-sensitive attributes, it is still a performance optimization, but applied later than the early hints.
My point is the following part of the RFC:
However, these header fields only provide hints to the client; they do not replace the header fields on the final response.
My interpretation is that we can perform preload etc as hints but we shouldn't interpret them as un-early (e.g. plumbing these headers to the document).
My point is the following part of the RFC:
However, these header fields only provide hints to the client; they do not replace the header fields on the final response.
My interpretation is that we can perform preload etc as hints but we shouldn't interpret them as un-early (e.g. plumbing these headers to the document).
By treating them as unearly I mean to wait until media is known before processing them, not doing any special embedding in the document.
I believe that would work better than ignoring the media attributes and load unnecessary resources in advance, while still being true to the spirit of the RFC.
We should have a separate discussion about the 'blocking' keyword in early hints, as that does have an effect on the document.
Currently the
media
,imagesrcset
, andimagesizes
are ignored for early hints. This means that an early hint to preload a mobile-only image would still preload it on desktop.I'm suggesting, instead, that those attributes are respected, but that for a start those links become un-early (they're treated as regular link headers, processed upon document initialization).
This would make the link header spec a bit more aligned, and perhaps fitting better with developer intent.
@yoavweiss @bashi @nhiroki please CC whoever else :)