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

[ResourcePriorities] Lazyload spec clarifications and suggestions

From: Bruno Racineux <bruno@hexanet.net>
Date: Wed, 17 Jul 2013 17:17:23 -0700
To: <public-web-perf@w3.org>
Message-ID: <CE0A42CE.6D6E9%webmaster@hexanet.com>
I have been discussing 'script preloading' over at the WHATWG list and have
been pointed to 'lazyload'.

I'd like to try and clarify something that I do not see in the specs, and a
couple previous points I came across in previous recent threads.

First, Simon Pieters said: "Blink blocks the load event on <script async>.
Is that a bug? It seems
someone would've complained by now."

It does not appear to be a bug as long the script started fetching prior, as
per spec [1] saying:
"Fetching an external script must delay the load event of the element's
document until the task that is queued by the networking task source once
the resource has been fetched (defined above) has been run."
The spec [3] would need respective updates to section 4.3.1 The script
element [1], in regard to lazyload.


Second, the lazyload spec [3] currently mentions: "If a script element has
both the defer and lazyload attributes specified, the lazyload attribute
MUST take precedence".

While that seems to imply that lazyload scripts are further down the
priority of defer scripts.
However that does not tell me if a lazyload script is expected to held up
for, until execution?

As developers we need a clear sensible indication as to when lazyload
scripts can start executing, in order to be able to actually register onload
events on them with external scripts.

If you take the execution sequence of the spec [3],  my expectation is/would
be the following:

1. readyState.interactive fires
2. Execute the "list of scripts that will execute when the document has
finished parsing".(defer, etc)
3. DOMContentLoaded fires
4. Execute the "set of scripts that will execute ASAP".
5. readyState.complete fires
6. Start executing lazyload scripts ASAP
7. window.load (not held by lazyload elements)

I don't see a major issue with the assumption put forth by Jatinder:
"However, this does mean developers will need to register an onload handler
for lazyload elements that they're interested in tracking. Is this a
reasonable expectation?" [4]

As long as I know, at which stage lazyload scripts are meant to be executed..
Without such requirement any lazyload script could execute before a 'defer'
script, which would not be a reasonable expectation.
This would also mean a necessary revision of "8.2.6 The end" [3] with a
specified priority given to 'lazyload'.
i.e. lazyload scripts should NOT be considered "scripts that will execute
ASAP" especially not at 'interactive'.

I propose it to be after 'complete' to clearly indicate that 'lazyload' is
post-DOMReady (or as generally assumed as DOMReady). Perhaps the download
for all other lazyload element should not start before 'complete' either, or
a least not before DOMContentLoaded fires, to allow the removal of lazyload
elements via events handlers on 'interactive' (when the DOM can be fully
manipulated).


Finally I would just like to suggest calling it 'delay' which is slightly
shorter than 'lazyload' and perhaps less of a technical geeky termŠ

Bruno

[1] 
http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#restrictions-f
or-contents-of-script-elements
[2] http://www.w3.org/TR/2011/WD-html5-20110525/the-end.html#the-end
[3] 
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overvie
w.html
[4] http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0026.html
Received on Thursday, 18 July 2013 11:58:46 UTC

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