Subresource link headers are implemented but not specified

[noamr]

This feature allows the browser to read the link headers of subresources and use them to preload other subresources. A common use case is to preload fonts from a stylesheet. See previous attempt to spec this: https://github.com/whatwg/html/pull/7691

This should probably be either specified or removed from implementations.

[noamr]

I was involved in spec'ing it and reached a conclusion that it's a problematic feature, and that speculative preloading based on the contents of a style/script in conjunction with standard document preloads is a better alternative.

A subresource doesn't have the whole picture. For example, a style knows that it points to webfonts, but it doesn't know if the DOM is going to include text that uses these fonts in practice. Only the HTML itself knows whether it is a good/bad idea to preload the font, and preloading it based on a link header from the stylesheet can end up with preloading unused fonts.

The place where this is useful with minimal footguns is with deep nested stylesheet imports and deep nested JS modules, as the style/script can guarantee that those resources are going to be needed (and even then, they could be media-gated etc so the footgun is still there).

So I've reached a conclusion that preloads is something that only the document should be doing and it shouldn't be chained.

@yoavweiss wdyt?

[0xdevwrite]

A subresource doesn't have the whole picture...Only the HTML itself knows whether it is a good/bad idea to preload...

Agree with this point, but instead of abandoning link header preloading of subresources altogether, it might make sense to allow subresources to specify their preloads and then have the parent document send a header to opt-in to "use" the link preload headers present in the subresource.

This allows the parent document to not need to know about all the subresources that a subresource might load and instead defer that decision to the subresource itself.

[pmeenan]

Separate from preloads, the link header is also used for compression dictionaries to trigger the async fetch of a dictionary that would be used for future requests. For example, an API call with a JSON response might link to the compression dictionary for the API and future API calls would use it.

Presumably the dictionary could be loaded by script injecting a link tag instead but, at least for this case, the subresource does have all of the context it needs to specify the dictionary.