Bugzilla

<link rel="preload"> is intended to deliver the (unprocessed) content data to the requesting content process as soon as possible after encountered and held in both the http cache and in an in-memory (preload) cache on the requesting content process.

Based on that and the following I decided to implement it as a speculative load with a flag to raise its priority.

- When fission is enabled the the link-preload preloaded content will be present in the right content process, as both are scoped by {schema:eTLD+1}
- With fission disabled, content processes subsume scoping for preload scoping
- Speculative loads are already coalesced by `nsHtml5TreeOpExecutor.mPreloadedURLs` hash table
- Speculative loads already handle CSP, SW, webext, redirects, so no new code for that is needed
- If decision to scope preloads is to be not just per document (what speculative loads provide) but also, when unused, for the whole document group, we just need a new service on the content process that can be searched for existing unused preloads; let's implement this as a followup, if the decision is made that way
- We want to handle <link rel=preload> as a speculative load anyway, as was the original motivation for bug 1393540 (which this bug renders as a duplicate)

<link rel="preload"> is intended to deliver the (unprocessed) content data to the requesting content process as soon as possible after encountered and held in both the http cache and in an in-memory (preload) cache on the requesting content process.

Based on that and the following I decided to implement it as a speculative load with a flag to raise its priority.

- When fission is enabled the link-preload preloaded content will be present in the right content process, as both are scoped by {schema:eTLD+1}
- With fission disabled, content processes subsume scoping for preload scoping
- Speculative loads are already coalesced by `nsHtml5TreeOpExecutor.mPreloadedURLs` hash table
- Speculative loads already handle CSP, SW, webext, redirects, so no new code for that is needed
- If decision to scope preloads is to be not just per document (what speculative loads provide) but also, when unused, for the whole document group, we just need a new service on the content process that can be searched for existing unused preloads; let's implement this as a followup, if the decision is made that way
- We want to handle <link rel=preload> as a speculative load anyway, as was the original motivation for bug 1393540 (which this bug renders as a duplicate)