Merge priority hints with lazy loading?

[pmeenan]

As part of the Chrome origin trial, a fairly common question was "what effect does priority hints have on lazyload?".

It doesn't (directly anyway), but maybe instead of a separate importance attribute we should just extend the enumerations for the loading attribute to also cover priority hints and extend it to the other elements where lazyload doesn't apply (just making lazy equivalent to eager for those elements).

Something like:

Keyword	State	Priority	Description
urgent	Eager	High	Used to fetch a resource immediately with high priority.
eager	Eager	Normal	Used to fetch a resource immediately with default priority; the default state.
idle	Eager	Low	Used to fetch a resource immediately with low priority.
lazy	Lazy	Normal	Used to defer fetching a resource until some conditions are met.

It would be backwards compatible for browsers that support lazyload but not priority hints since the default value for unrecognized values is eager.

Extending the loading attribute also makes it very clear that the prioritization is limited to the loading of the resource (another often confusing point around importance). It is also a bit shorter which could help with #35 and it keeps the explosion if attributes under control.

At the fetch layer, the same attributes could also make sense on a loading attribute for the Request with the exception of lazy. That should be clean spec-wise though since lazy impacts the time when the fetch is initiated and isn't an attribute of the fetch itself.

[addyosmani]

Overall, I like the idea of extending loading's enumerations to cover the use-cases offered by the importance attribute. It could give us a single attribute for loading prioritization that we could rally around. Some misc thoughts:

• If we go down this direction, we should probably survey developers to learn about their expectations of these enum values, right? e.g. with <script>, what would they expect <script loading=lazy> to do vs <script loading=idle>?. It may also become important to provide clear examples (maybe even in spec) of when to use <img loading=idle> vs lazy (I myself am having a hard time mapping the latter to something concrete).
• With loading=lazy, extensive discussion was required to land on the behavior for specific kinds of resources such as images and iframes (e.g. heuristics / distance-from-viewport thresholds). If we were to merge PR with loading, would a similar exercise be needed for each resource type not currently covered by the loading attribute? (scripts, <video> etc) or would the spec keep this relatively high-level? A meta-comment is that depending on how explicit we want the behavior to be, it could impact both complexity/ease of vendor adoption and timelines for the feature being available outside of Chromium.

At the fetch layer, the same attributes could also make sense on a loading attribute for the Request with the exception of lazy. That should be clean spec-wise though since lazy impacts the time when the fetch is initiated and isn't an attribute of the fetch itself.

👍🏻

[pmeenan]

I think we'd want to limit lazy to elements where it makes sense and only support urgent, eager, and idle for scripts, preload, etc. Maybe map lazy to idle in those cases but it feels like it is probably better to leave it as unrecognized for the element types that don't support it.

[andydavies]

Having a single attribute make a lot of sense to me

I'm less sure about idle as a value for low priority and how it'll be interpreted e.g. will people assume it means network idle?

[pmeenan]

I'm a bit split in general. The existing eager also makes it feel like something high priority (and isn't immediately clear that it's lower than urgent) while the high, low and auto from importance feel pretty clear (but loading=low doesn't quite come across right either).

If we want to move forward with extending loading, maybe add auto as a level and make eager a backwards-compatible alias for auto.

It might be cleaner to just keep them separate and decide later if the scope of importance should impact anything beyond loading but leave it at just resource-loading for now.

[pmeenan]

I'm going to close this for now. Can re-open it if the TAG decides it is worth looking at or if it is cleaner to keep them separate.