Indicating probability of using a hint: required, speculative...

[igrigorik]

Not all hints are made equal. Sometimes you have high confidence that a resource will be needed in the future, other times you only have a weak signal, and sometimes you know a resource will be needed. We need a mechanism to indicate these priorities/probabilities to the user agent, such that it can take this into account when determining:

• (a) whether the hint should be executed.
• (b) how much work it should do (i.e. full processing vs partial processing).

My proposal is that we expose an enum: {required, high, medium, low}. Full description: http://igrigorik.github.io/resource-hints/#required-vs-speculative-execution

• required is a MUST execute - i.e. as a developer I'm 100% certain this will be needed.
• high, medium, low are indicators of speculative hint, and SHOULD be processed by the user agent on best-effort basis.

Exposing this enum allows us to merge prefetch/prerender (see https://github.com/igrigorik/resource-hints/issues/2), and provides a way to mark required fetches (see https://github.com/igrigorik/resource-hints/issues/7).

Question: best mechanism to expose this enum? Extra attribute on link? A modifier on rel attribute?

<link rel="preload" priority="required" href="/app.js" context="script">
<link rel="preload;required" href="/app.js" context="script">

Other ideas?

/cc @willchan @annevk @marcoscaceres

[annevk]

Didn't the Web Performance WG have such an attribute? lazyload or some such? Where did that go?

[willchan]

My teammates and I are still against it. I'd rather expose lower level primitives with better defined semantics, like resource hints.

[igrigorik]

@annevk as specced, lazyload is a modifier that lowers the download priority of a resource relative to other resources on the page. What I'm after here is different: a way to specify the execution priority (perhaps 'probability' may be a better word) of the hint itself. The download priority is a separate concern once and if the hint is executed.

As a brief aside... I think the combination of preload + required and an extra mechanism to communicate download priority would allow us to implement lazyload with lower-level building blocks. Better, it would be far more flexible: lazyload does not allow you to control when and in which order the resources are processed and applied. In short, I'm with Will, we can deliver a better and more flexible solution than what Resource Priorities spec currently provides.

[hexalys]

lazyload does indeed lack such precision. But your required signal is not that different, unless devs can have a clear expectation as to when those scripts as supposed to be ready.

In that, I don't really see myself using 'high, medium, low' indicators at all for web sites. It may well suited for apps which require the scripts way past window.load. But for rendering performance, I like to know when my scripts are going to be ready, along the document readiness. Waiting for them to load isn't always an option. required alone is otherwise not that different from defer in practice.

Thus in addition to speculative enums or as my preferred substitute. I suggest having more precise required signals, using interactive and complete enums (relative to the document states), DOMContentLoaded and load. Or the same keywords as Navigation Timing.

[igrigorik]

@hexalys I think you're misunderstanding the intent of proposed signals.

• required hints must be executed by the user agent when processed.
• high, medium, low are speculative hints that should be processed on a best-effort basis by the user agent (i.e. these are signals for next page load and they are not restricted to preload.. prerender+low for a low probability next navigation target).

As such, think of required as a signal for a resource that must be downloaded because you know that it will be used within the current navigation context. On the other hand, when predicting the future (i.e. next navigation), you need a way to signal the probability of using specified resource - hence speculative hint and associated low, medium, high execution priorities.

Also, the preload hint is, effectively, a declarative fetch directive to the preloader. If the resource that's being fetched needs to be a blocking resource, inject a matching script, style, etc, tag that will match the resource and give you the desired behavior? I want to separate downloading from processing.

[hexalys]

Ok, I wasn't fully picturing high, medium, low for "next navigation". I now get it.

If the resource that's being fetched needs to be a blocking resource, inject a matching script, style, etc, tag that will match the resource and give you the desired behavior?

I suppose that works, yes. And we'd be simply using hints order as blocking script priority. Would an inline script at bottom work too, without race conditions?

Regarding (a) and (b): required should only do partial processing though yes? (e.g. just parsing scripts). Leaving the reordering and managing of possible dependencies separately.

[igrigorik]

The order in which the hint-initiated download is initiated is not important, what's important is how you process them - i.e. the order in which you inject the matching requests (scripts, stylesheets, etc). And yes, an inline script at the bottom should work as expected: the interactive event is fired once we've finished constructing the DOM.. and we'd have to execute the script before we can do that.

Finally, required doesn't indicate anything about processing, the type of hint does: preload is simply a download instruction, with no further work, whereas prerender may apply relevant processing based on available resources, content-type, and other conditions.

[bizzbyster]

What's wrong with just supplying a probability of use as an integer between 1-100?

Peter

[hexalys]

@igrigorik The phrase from your link "required hints must be executed by the user agent" is what confused me. The preload part of the spec is indeed clear on that. The words processed or preprocessed would be better in the broader "Processing model" context, to prevent confusion, notably with script execution.

[igrigorik]

@bizzbyster nothing. I initially ruled it out due to concerns over exposing "too much", but I'm happy to be convinced to go back on that. I'd map it to [0-1.0] and just note that 1.0 indicates that the hint is a must execute, whereas anything <1.0 is a should and best-effort.

@hexalys the use of "executed" in the processing model section is intentional on my part. There are two separate decisions here: first, is whether the hint is executed by the client (i.e. is the download initiated), second is whether the response is processed (i.e. script is executed, image is decoded and so on)... That said, I do see some places where I need to tighten up the language to make this clearer.

[bizzbyster]

Excellent. This approach (supplying a probability) works great for the "Site Hinting Service" we are building that calculates probability based on past visits to the site. Hope others agree that this is not too much information.

[hexalys]

@igrigorik I see the use of probability attributes in your slides. Just noting that we should try and keep all new attributes as short as possible. At or under 8 characters at the maximum length in my view, as best effort to keep overall page sizes under control.

prob would be ok. But what about simply using hint ;).

[yoavweiss]

@hexalys - gzip makes this practically irrelevant. Readability is way more important

[igrigorik]

Updated to use probability in https://github.com/igrigorik/resource-hints/commit/04e873b64a24fa2d16e1d65da6045ece21ff6aa8. Let me know how that looks: https://igrigorik.github.io/resource-hints/#required-vs-speculative-execution

[hexalys]

@yoavweiss I think we already had that argument... I still disagree to some degree, especially if a shorter attribute can be found with no readability downside. 'prob' isn't very readable, noted.

But hint in this case convey the proper connotation of/with the spec. rel defines the resource hint type, and hint define the hint. If not adequate then why call it 'resource hints'?

[igrigorik]

@hexalys to me hint does not imply probability.

[igrigorik]

Closing this thread. If you see issues with the new language, feel free to open a new bug or reopen/comment on this one.