Html: Questions about the link rel preload

Created on 16 Jul 2018  ·  4Comments  ·  Source: whatwg/html

From the spec, does it mean:

  • Does 'priority' is relative to the preload resources? My doubt is that if we use preload to load a resource, the resource will be lift up to the top to load after the html be parsed, so I don't know what does 'priority' means because it already has a very high priority(relative to normal resources)

The preload keyword indicates that the user agent must preemptively fetch and cache the specified resource according to the potential destination given by the as attribute (and the priority associated with the corresponding destination)

  • According to the spec, what's the relationship between 'as' and 'priority', IMO, from this:

  • I find that if I preload a image and set the 'as' attribute with 'style/script/...', and use it as <img src="..." >, the preload will be canceled(in chrome and safari), and if I don't set the 'as' attribute(default is 'xhr'?), it won't be cancelled and will be decoded as something(I don't know whether the laster img tag can use it), and if I set the 'as' attribute with 'image', it will works. But seems that the spec doesn't mention all these situations?


    • My personal summary is that the 'as' attribute must be consistent with the actual type of the resource and the html tag which use it? Or it will be cancelled or doesn't work as expect?

And what does high priority represente? More bandwidth? Or less queue/stalled time? Or something else?

Thanks.

Most helpful comment

Indeed. If they do, surely they will catch up. In the meantime, closing this. Thanks.

All 4 comments

/cc @domfarolino @yoavweiss

Answering your questions in an order I think will be most helpful:

what's the relationship between 'as' and 'priority'

User agents currently determine the priority of a request given it's destination (among other things). A browser might prioritize "style" and "script" destinations quite high, while "image" destinations might be much lower. (We'll get to what exactly "priority" means in a bit). So in many cases the ultimate priority a request receives is heavily influenced by its destination (think "type"). The as attribute value tells the UA what the destination of the request is, and thus happens to play a role in "setting" it's ultimate priority. Its primary purpose though, is to tell the browser what kind of later requests for that resource can actually use it, which I imagine is why your seeing cancellations for some "invalid" uses. Domenic/Yoav may be able to speak to that better though.

And what does high priority represente?

Priority in general is very unspecified. Presently, Fetch doesn't take much responsibility here, so the term "priority" can mean many things. In Chrome, this means queueing or stalling time, h2 stream priority, or more (potentially bandwidth alloc, but not sure off the top of my head). Point is, it can mean any UA-specific action that doesn't break normative behavior. Until this is specified in standards, it is very hand-wavy.

so I don't know what does 'priority' means because it already has a very high priority

Sorta. It's true that a lot of preload requests are "discovered" earlier than others, as they are often close to the top. Yoav explains this as "preloads jumping the queue", as certain preloads that might correspond to a lower-priority destination are now getting fetched way earlier than other high-priority things. Early discovery time doesn't quite mean high priority though, because these early discovered requests might be fetched with low priority depending on the UA's action, often influenced by the destination. Hopefully that makes sense.

@domfarolino Thanks for your clarification! Thanks.

@domenic @yoavweiss So do you have any supplemental?

Indeed. If they do, surely they will catch up. In the meantime, closing this. Thanks.

Was this page helpful?
0 / 5 - 0 ratings