If you look at the network panel you'll see we actually downloaded the script twice!

Can you try adding "as='script'" to the link element? Somehow the requests are not being coalesced.

This version adds as="script" to the preload link: https://www.scirra.com/labs/bugs/preloadscript2/

Appears to work correctly. No console warning and single network request.

Yoav, that's WAI, right? I wonder if we should amend the console message to warn about this possible mistake.

Yeah, that's WAI. Since this is the second time people complain about the warnings instead of looking for double downloads, the warning is clearly not clear enough.

Any suggestions for improvements? How about
"The resource https://www.scirra.com/labs/bugs/preloadscript/preloaded.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has the right `as` value, was really needed and wasn't double downloaded."

Wait, so this is to spec? If you don't put "as" then it is correct for Chrome to make two separate requests, which is even less optimal than not using preload at all?

That is one nasty gotcha.

If you don't put the correct `as` value, the browser cannot know which CSP directive to apply to the resource and which resource type it is (as well as which priorities to assign to the resource and what Accept headers to include in the request).

That means that the browser cannot reuse the downloaded resource without potentially breaking security (similar to the way that it can't reuse a resource downloaded with `<img src>` as a response to a `<script src>`)

Similarly, you also have to set the right `crossorigin` attribute value, depending on the resource you're fetching (e.g. font, XHR)

Shouldn't link rel="preload" with no "as" attribute just do nothing then? Why make a request at all? Or maybe the warning should appear as soon as the link tag parses warning that there's no "as" attribute?

A missing or empty `as` value maps to the empty/default fetch destination, which is the same as XHR, sendBeacon(), etc. See https://fetch.spec.whatwg.org/#concept-request-destination

It might be worth while to add a spec note pointing out the fact that a wrong `as` value fetch will not be reused.

Maybe link rel="preload" should require the "as" attribute else log a warning, and if the developer intends to have the behavior you describe for a missing "as" attribute, then explicitly opt-in with as="fetch"?

Ash - your comment in #9 suggests a spec change. Would you mind opening an issue on https://github.com/w3c/preload/issues ?

In case of a spec change, I'll happily modify implementation to match it, but I think it'd require a separate tracking bug. Closing this one as there's no immediate action on it, and initial issue is WAI.

Filed https://github.com/w3c/preload/issues/80

Just want to pop in and say I'm seeing this for link header/elements that specify a valid "as" attribute. You can see it in at least Chrome 55 by visiting https://lodash.com/ which specifies link headers or https://knowitall-9a92e.firebaseapp.com/ which specifies link elements.

John - you are seeing these warnings because you *are* double downloading resources. Both sites are using both "preload" and "prefetch" for the same resources which is triggering 2 downloads of each resource.

Aa a side note - trying to *preload all the things!!* is probably not the best way to go. You should pick specific late discovered resources that you want loaded earlier and use preload to tell the browser about them.

As another side note, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=676887 to avoid "prefetch" from loading is these kind of scenarios. (still doesn't mean it should be used that way...)

@yoav I actually saw the issue too when using only preload directives. I was experimenting with both preload and prefetch. I have reverted to just using preload and the issue is still there.

@john - interesting. In any case the problem is not the warnings, but the double downloads that you (and your users) are experiencing :/ I'll dig further, but the fact that the warnings made you notice there's a problem show that they're doing their job.

> In any case the problem is not the warnings, but the double downloads that you

I'm only specifying a "preload" so there should be no double downloading. If there's double downloading then the warning needs to be adjusted to reflect that. The message is pretty cryptic as is.

One issue we're seeing here: lack of `integrity` property on preloads. Filed at https://bugs.chromium.org/p/chromium/issues/detail?id=677022

I have removed the integrity attribute from files served from the same origin. This has removed many of the warnings though a few are stilling coming through.

So, the integrity attribute is one issue.
I also see a couple of woff2 files fontawesome that are being fetched as raw resources rather than fonts, and therefore not being matched and reused.

Lastly, sw.js is preloaded as a "script", which is not the right destination. Even if it would be preloaded as "serviceworker" (which is the right destination), that's not currently supported.

If the <script> element was at the bottom of body e.g.

    <script src="//code.jquery.com/jquery-2.2.4.min.js"
        integrity="sha256-BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44="
		crossorigin="anonymous"></script>
    </body>

And I have

<link rel="preload" href="//code.jquery.com/jquery-2.2.4.min.js" as="script" crossorigin />

or

<link rel="preload" href="//code.jquery.com/jquery-2.2.4.min.js" as="script" />

in <head>

Should I still get

The resource http://code.jquery.com/jquery-2.2.4.min.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing. 

That's a current issue, related to the `integrity` attribute. See https://bugs.chromium.org/p/chromium/issues/detail?id=677022