- 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