Early hints: media, imagesrcset, imagesizes

[noamr]

Currently the media, imagesrcset, and imagesizes 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 :)

[yoavweiss]

/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.

[bashi]

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

[noamr]

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.

[bashi]

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).

[noamr]

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.