Specifying or using preload twice

[yutakahirano]

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.

1. 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.)
2. 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

[yoavweiss]

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.

<img src=foo>
<script src=foo></script>

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]

As far as I know nothing allows for deduplication at the moment.

[igrigorik]

If you preload a no-store image and then load it twice via two img elements.. 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]

If someone could actually define preloading (and write tests) we'd no longer need to have these conversations.

[yoavweiss]

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 2 fetch("foo") calls will not, regardless of preload.

[annevk]

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]

True, but the same is true for <script src=foo><script src=foo> which isn't deduped in HTML AFAIK.

[yutakahirano]

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]

That is specified actually. That's because HTML has image URL deduplication. (I forgot about that above, because it happens above the Fetch layer.)

Sorry for my ignorance, can you give me a link? I'm interested in how it's defined.

[annevk]

@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]

@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]

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]

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]

@annevk Thank you.

[yoavweiss]

This needs specifying as part of #97

[igrigorik]

Added a note in #97 to address this.. let's continue discussion there to consolidate threads.