WIP: Define the prefetch cache

[noamr]

• 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 )
/links.html ( diff )

[noamr]

This PR is meant to drive the conversation towards consensus around prefetch.

It tries to provide behavior close to preload, in the sense that a prefetched resource doesn't have to revalidate the cache in certain conditions, but without the arbitrary 5 minutes rule.

How it works:

• The prefetch cache is not accessible in itself, it's used as a funnel to populate the preload cache for the current and subsequent documents.
• When a prefetch link is found, it is preloaded like a preload link, but is also added to a map of prefetched resources. Fetch already has wording that allows it to lower the priority of requests with a prefetch destination.
• Upon navigation, the prefetched resources that have already been fetched are snapshotted from the active document of the same browsing context as well as from the source browsing context (e.g. the iframe's parent)
• When the new document is created, the prefetched resources snapshotted in that same navigation are applied to that document as if they were preloads, very similar to Link headers, if their initiator was from the same origin.
• In-flight requests are not supported. That's because fetches from a particular document are aborted when the document is unloaded. In the future we can consider not aborting some of these requests.

TODO:

• Comply with no-store
• Check CSP upon transferring to new document
• ...

[domenic]

What is the relationship between this work and the work @jeremyroman has been doing in https://wicg.github.io/nav-speculation/prefetch.html ? Is this just an upstreaming of that? That work is still settling, see e.g. WICG/nav-speculation#151 ... I'd like to ensure this is coordinated, so perhaps Jeremy should be the first reviewer here before we do HTML Standard review work.

[noamr]

What is the relationship between this work and the work @jeremyroman has been doing in https://wicg.github.io/nav-speculation/prefetch.html ? Is this just an upstreaming of that? That work is still settling, see e.g. WICG/nav-speculation#151 ... I'd like to ensure this is coordinated, so perhaps Jeremy should be the first reviewer here before we do HTML Standard review work.

It's totally parallel, the only relation being the word prefetch.

Part of the past conversations like this one were about separating the two use-cases.

Jeremy's work is particularly about navigation prefetching, which is more of a new feature, with a lot of work around cross-origin prefetching, while this is to define the existing <link rel=prefetch>, specificially for fetching subresoures for future navigation in same-origin contexts. See this discussion.

@jeremyroman if I got something wrong here and you're also doing something with <link rel=prefetch> please correct me :)

[yoavweiss]

/cc @yutakahirano for Chromium thoughts on the PR

[yutakahirano]

I'm not very familiar with prefetching. @nyaxt, do you?

[domenic]

I talked with Jeremy a bit offline and he echoed my confusion a bit; we both thought <link rel=prefetch> was for navigational prefetching, and did not know people were using it for subresource-for-upcoming-navigation prefetching. I see that w3c/resource-hints#86 has much more background. Jeremy and I will engage over there.