RE: [ResourcePriorities] Spec updates

Will,

There had been some feedback that without any MUST clauses the spec makes it very difficult to test implementation conformance. One of our goals was to make lazyload a hint to the user agent, such that the user agent could use that hint in cases of network contention to reduce the download priority of a resource. Similarly, in cases of no network content, the user agent could choose to ignore the lazyload hint, and download the resources as if the lazyload attribute wasn't specified.

I think the current spec text with the MUST clause instead of the MAY clause still maintains that spirit. The term network resource contention is defined as 'when the User Agent determines there is a conflict over access to network resources', so the user agent can decide to ignore the hint if it doesn't believe this is a case of network resource contention.

This feature is useful with HTTP1.1 as well, so we shouldn't limit it to HTTP/2.

Thanks,
Jatinder

From: willchan@google.com [mailto:willchan@google.com] On Behalf Of William Chan (???)
Sent: Sunday, September 1, 2013 3:56 PM
To: Jatinder Mann
Cc: public-web-perf@w3.org
Subject: Re: [ResourcePriorities] Spec updates

I have concerns about section 4.2 (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#lazyload-attribute):
"""
The lazyload attribute indicates the priority order in which the User Agent will download the resource associated with the element in cases of network resource contention.

If the lazyload attribute has been specified on an element and the User Agent determines that there is network resource contention, the User Agent MUST delay downloading the resource until after all other elements without the lazyload attribute that will be fetching a resource have started downloading.
"""

In particular, I dislike this MUST, or perhaps I dislike the "delay downloading". This is vague and perhaps too restrictive. Due to how resource discovery works, resources with the lazyload attribute set may be discovered before resources without said attribute. I don't see how to enforce this MUST at all. And I don't know that it makes sense. Also, I don't see what's wrong in HTTP/2 with fetching a resource with the lazyload attribute before a resource without the attribute, as long as the priority is appropriately tagged in HTTP/2.

Cheers.

On Tue, Aug 20, 2013 at 4:09 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
Based on feedback from the working group, I have made some updates to the Resource Priorities spec, https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html:


-          Added the postpone attribute

The use case of never downloading a resource until its viewable by the user seems compelling from a system resources, server resources, and user bandwidth (e.g., mobile user) scenarios, but it does feel functionally different from the lazyload concept, where in cases of network contention connections are given to higher priority resources. I've added a new postpone attribute to describe the case where we don't want resources to be downloaded if they aren't formatted to be visible or are not in the viewport. This attribute only applies to resources that can be laid out.


-          Defined script download and execution behavior

For the script element, I've added more details on its expected execution behavior. The lazyload attribute delays downloading script in network contention scenarios, and will execute the script asynchronously soon as its available. Lazyload in this way behaves more closely to async than defer. I was initially considering changing the script execution behavior based on whether lazyload is used with defer or async (e.g., <script async lazyload> or <script defer lazyload>, but for now I have left it to be more closely aligned with async. As defer scripts take ordering into account, we would need to create a separate queue for <script lazyload defer> scripts, otherwise any <script defer> that came after a <script lazyload defer> would implicitly be lazyloaded as well.


-          Added MUST clauses

There was feedback that if the spec only has optional clauses, there will be very little to test. I have updated the spec to have MUST clauses, but have left the definition of the network resource contention and visibility generic enough that User Agents can choose to optimize here as needed.



-          Updated events behavior

The load event of the Document isn't delayed by resources with lazyload or postpone. In case developers are interested in tracking when all of their lazyloaded resources have actually loaded, I have specified a lazyloaded event that fires at that time. I haven't provided a similar event for postpone as I am assuming most developers would want to track those using load events on the element directly.



-          Added both IDL and content attributes

I've made the attributes both IDL and content attributes, to be consistent with other similar attributes and help with feature detection.



-          Added use cases to introduction section

I have added more use cases and examples to the introduction section.

Please review and provide feedback.

Thanks,
Jatinder