WIP: Subresource link header

[noamr]

(On top of #7866, waiting for it to be merged)

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/images.html ( diff )
/index.html ( diff )
/links.html ( diff )
/semantics.html ( diff )
/webappapis.html ( diff )

[domenic]

@noamr I've lost track of what this is attempting to do. Is it still relevant?

[noamr]

@noamr I've lost track of what this is attempting to do. Is it still relevant?

I think we got stuck a bit on this. It's a shipped feature in some browsers so it's definitely still relevant to spec it.

[domenic]

Sorry, what is the actual feature? That's what I lost context on.

[noamr]

Sorry, what is the actual feature? That's what I lost context on.

Processing Link headers from subresource responses (e.g. a script telling you which other scripts to preload, a style telling you which sub-styles or even fonts to download).
This is not in wide use, and the industry kind of moved on to bundlers.

One real use case I think for this though is for same-origin document prefetching, as a non-speculative alternative to speculationrules and no-state prefetch: you prefetch the next document with <link rel=prefetch> and that document returns the document plus link headers with the important subresources to preload.

[noamr]

Not pursuing this atm.