W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2013

Re: [ResourcePriorities] Spec updates

From: Bruno Racineux <bruno@hexanet.net>
Date: Thu, 10 Oct 2013 15:11:35 -0700
To: Jatinder Mann <jmann@microsoft.com>
CC: <public-web-perf@w3.org>
Message-ID: <CE7C4ECF.75540%bruno@hexanet.net>

From:  Jatinder Mann <jmann@microsoft.com>
Date:  Tuesday, August 20, 2013 4:09 PM
> 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.

It looks like a good approach, and addresses some of my previous concerns in
terms of script priority.
> -         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.

There is no mention as to whether lazyload also applies to inline scripts
(without src) or not?
I am also a big advocate of restoring 'defer' for inline scripts which was
deprecated from HTML4 with insufficient reasons in my view. I have tried to
explain to Ian Hickson that 'defer' for inline scripts is extremely useful
with a example at: 
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg35785.html
(search for 'defer on inline script blocks' or 'ordered defer')

Not having 'defer' if the src attribute is not present, breaks the resources
priority chain with external scripts. It doesn't seem logical to deprive
"some" scripts from the 'defer' behavior, solely based on the provenance of
the source code, when the browser consider them all as one ordered chain of
events of the same type.

Can we also please reconsider or re-evaluate 'defer without src' along this
Resource Priority context?
> -         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.

Ok, though non-blocking aside, I am still not clear from the specs as to
when 'lazyloaded' resources are expected to start loading? Is it on
DOMContentLoaded or at/before readyState.complete?

Technically remaining 'resources that delay the load event' are processed in
between those two [1].
The lazyload resources should technically start right after step 6 when:
"the event loop until there is nothing that delays the load event in the
Document", say at step "6.5"... It that correct?

[1] http://www.w3.org/TR/2011/WD-html5-20110525/the-end.html#the-end
Received on Thursday, 10 October 2013 22:12:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC