This repository was archived by the owner on May 5, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on May 5, 2022. It is now read-only.
Specifying or using preload twice #85
Description
Hi, I have several questions regarding reusing preloads.
<link rel="preload" href="/resource">
<script>
let p1 = fetch("/resource");
let p2 = fetch("/resource");
</script>
Assume "/resource" is served with "cache-control: no-store" header.
- Should / can we use the response fetched by the link element to the first fetch() call? (I believe yes. Although "no-store" is specified, the preloaded resource has not been used, so using it is fine.)
- Should / can we use the response fetched by the link element to the second fetch() call? (I believe no. As the resource is used by the first fetch call, reusing it violates the HTTP cache semantics.)
If my guesses for the questions are correct, what is the preferred way to preload twice? Is the following code fine?
<link rel="preload" href="/resource">
<link rel="preload" href="/resource">
<script>
let p1 = fetch("/resource");
let p2 = fetch("/resource");
</script>
cc: @yoavweiss, @annevk, @hiroshige-g
Activity
yoavweiss commentedon Feb 8, 2017
My intuition regarding those questions matches yours. I'm not sure if/how the "preload twice" scenario would work, nor do I think it's a major use-case.
In general, I'm not aware of resource reuse rules being specified for preload or for other resource fetches.
e.g.
is likely to result in two resource fetches (which may or may not be coalesced at the network layer), but I'm not aware of this being defined anywhere. I think we should define those rules and document the current state. The Fetch spec is probably where these definitions should be.
annevk commentedon Feb 8, 2017
As far as I know nothing allows for deduplication at the moment.
igrigorik commentedon Feb 11, 2017
If you preload a no-store image and then load it twice via two
imgelements.. I believe, at least in Chrome, we'll end up reusing the same response in both cases -- right? Why would fetch() be different, instead of using an image element?annevk commentedon Feb 12, 2017
If someone could actually define preloading (and write tests) we'd no longer need to have these conversations.
yoavweiss commentedon Feb 12, 2017
I agree this needs specifying, but this is not specific to link preload.
e.g.
<img src=foo><img src=foo>will reuse the same response, while 2fetch("foo")calls will not, regardless of preload.annevk commentedon Feb 12, 2017
That is specified actually. That's because HTML has image URL deduplication. (I forgot about that above, because it happens above the Fetch layer.)
yoavweiss commentedon Feb 12, 2017
True, but the same is true for
<script src=foo><script src=foo>which isn't deduped in HTML AFAIK.yutakahirano commentedon Feb 13, 2017
I think basically keeping HTTP cache semantics is good though I know the cache in Blink (blink::MemoryCache) in not conformant.
Regarding fetch() / XHR, They're JS APIs and developers tend to want more consistent behavior for them than for img / css / etc, I think. I once got a request for XHR (https://crbug.com/333804) and the cache in Blink is now basically disabled for fetch() / XHR.
yutakahirano commentedon Feb 13, 2017
Sorry for my ignorance, can you give me a link? I'm interested in how it's defined.
annevk commentedon Feb 13, 2017
@yoavweiss that might be an issue with Blink then.
@yutakahirano https://html.spec.whatwg.org/multipage/embedded-content.html#the-list-of-available-images.
yoavweiss commentedon Feb 13, 2017
@annevk I disagree it's an issue in Blink, but it seems there's divergence here. http://jsbin.com/bovagohehu/edit?html,console,output outputs a single download for Chrome, and 2 for Firefox. AFAIK, Safari would also issue a single download here (but hard to test, as ResourceTiming is not yet exposed).
annevk commentedon Feb 13, 2017
It's an issue in Blink because it violates the standard. If you want that kind of behavior you'd need to work on standardizing it.
yoavweiss commentedon Feb 13, 2017
I don't disagree about the need for standardization, but not sure this behavior didn't precede current spec (this was the behavior in WebKit when I first started digging around that code in 2012)
yutakahirano commentedon Feb 13, 2017
@annevk Thank you.
yoavweiss commentedon May 31, 2017
This needs specifying as part of #97
igrigorik commentedon Jul 21, 2017
Added a note in #97 to address this.. let's continue discussion there to consolidate threads.