Should preload be more than a hint?

[jakearchibald]

We don't have primitives for preloading (for example) scripts, I was hoping "preload" would provide that by being a MUST, and providing a promise to signal completion.

What's the benefit of "preload" being a hint?

[igrigorik]

You mean preload and not execute right? Because nothing stops you from using a regular script tag to load it - put it in the head, slap async on it, etc.

As it stands, my intent behind rel=preload is to provide a declarative way to communicate with the preload scanner. Now, the interesting part is that while all modern browsers have one, none of them make any promises about when or whether it'll kick in - depends on page structure, available resources at runtime, browser flags, etc. That's why it reads as a "maybe" right now.

[jakearchibald]

You mean preload and not execute right?

Yeah.

my intent behind rel=preload is to provide a declarative way to communicate with the preload scanner.

Does that mean…

var link = document.createElement('link');
link.rel = "preload";
link.href = "whatever.img";
document.head.appendChild(link);

…must not trigger a request, since it has no interaction with the preload scanner?

[igrigorik]

It may trigger a request. Note that in order to use the response you'll also have to inject an img or send an XHR for it... in either case, there is more JS code. So, if you're scheduling a resource fetch for the current page, it's not clear to me why you wouldn't just inject the img or send the XHR in the first place?

[jakearchibald]

One use-case is script, where's it currently impossible to preload a script without executing it

[igrigorik]

If we make it a MUST, should it block onload? If the answer is no, then there is an interesting side effect: effectively, we've implemented lazyload [1]. It's a bit more involved than simply specifying an attribute, but it still seems reasonable:

1. Specify rel=preload hint with right context
2. Inject appropriate element referencing the preloaded resource (when needed, or after the preload onload event has fired, etc).. If anything, this provides even more flexibility as to when the resource is processed and applied.

Hmm? I kinda like it... :)

[1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload

[yoavweiss]

Wouldn't the discovery of the element referencing the resource cause blocking of onload? Should the fact that it was previously discovered by rel=preload override that?

If I get what you're suggesting regarding lazyload, I find it confusing that adding a preload hint/directive would effectively mean that the resource's priority is downgraded. I suspect most authors would expect the opposite.

[igrigorik]

Not sure I follow, why do you interpret it as "downgraded" priority?

The suggestion from @guypod was to treat preloaded resources as non-blocking unless there is a matching request that is initiated before the load event is fired -- i.e. preload is simply a directive to the network stack to initiate the download, but it doesn't say anything about whether this resource should block the load event.

[yoavweiss]

Not sure I follow, why do you interpret it as "downgraded" priority?

Maybe I misunderstood what you meant with "lazyload". Can you elaborate on that?

The suggestion from @guypod was to treat preloaded resources as non-blocking unless there is a matching request that is initiated before the load event is fired -- i.e. preload is simply a directive to the network stack to initiate the download, but it doesn't say anything about whether this resource should block the load event.

That sounds good to me.

[igrigorik]

Ah, I skipped a few details as well.. I was also thinking about the ability to pass down some priority information to fetch (as recently discussed on what-wg). Let me follow-up on this in a separate thread.. it requires a bit more careful thinking and explanation.

[igrigorik]

17 should provide a superset of what we're discussing here.. Closing this bug, let's continue the discussion there.