- From: Noam Rosenthal <notifications@github.com>
- Date: Thu, 23 Sep 2021 03:42:16 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 23 September 2021 10:42:28 UTC
> > Preload (IMO) should be roughly equivalent to asking the document whether it currently has a `<link rel="preload">` in the DOM and querying that element for its response, > > I like that. It makes it pretty easy to explain the scope of preloading to developers. Although, you'd need to figure out the behaviour of multiple preload elements in the same page with the same url etc. I'm imagining something like a ref-counted list of unique URLs. > > > and this is separate from any cache mechanism. > > If you mean it comes _before_ other cache mechanisms, then yeah. I drew this diagram a few years back ([source](https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#map-of-fetching)): What I meant is that it's not part of the HTTP cache or part of the image cache. Like in your diagram. > However, I think the fetches created by preload elements should take part in other caches and elements of the fetch pipeline (in both directions) I agree. The preload list should be agnostic to whether this URL is also cached somewhere else. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/590#issuecomment-925697278
Received on Thursday, 23 September 2021 10:42:28 UTC