RE: [ResourcePriorities] Only specify lazyload on img

The goal of this specification is to allow developers to give download priority hints on any resource that the browser will be downloading. Today most browsers use some sort of priority scheme on issuing network requests for resources based on document order and resource type. An example network request ordering could be root document, CSS in document order, JavaScript in document order, everything else in document order. By allowing the developer to give the browser insight into which resources are less important than others, the browser can better prioritize the order in which it makes the network requests. If the browser can optimize to make the most important network requests first, this will be a win for perceived and actual web page performance.

While the img element is the most obvious example of prioritizing a resource that effects the visuals of the page, JavaScript and CSS also have the ability to effect visuals. For example, one can break up below the fold visuals into a separate CSS file, and deprioritize its download using the lazyload attribute on the <link> element. On <script>, unlike defer, which just means don't execute until parsing of the document is complete, this is an even higher order de-prioritization. Downloading lower priority resources later will save the browser CPU costs of parsing, creating internal data structures, for script potentially compiling to native machine code, for the lower prioritize resources until later. 

I do think we still need to work out what this attribute means for <script>. Currently we were leaning towards not blocking the window onload event for lazyload scripts. However, does this mean a developer will need to register an onload handler on each script element to know when to execute the script? Or do we create a new event that indicates when all resources (including lazyloaded resources) has been loaded? Alternatively, we can leave the window's load event definition as is and create a new event that fires when all non-lazyloaded resources have loaded, such that scripts can trigger work off of that event instead of the window onload event. I think these concepts still need to discussed and worked out in the working group.

For SVG, I think it should more appropriately be labelled SVG images. The proposal should be updated.

I think we should talk more about media elements and iframes. The use case I was thinking for iframes was for advertisements, as you may not want the loading of your ads to impact how quickly your web page visuals load. However, I do recognize most ads are created dynamically through 3rd party scripts. However, I do like the idea of having a single well defined attribute that applies to all elements capable of downloading a resource, instead of defining different attributes for each. Remember that this attribute is only a hint to the browser; in favorable conditions, the browser may choose to ignore the hints and just download resources in a different order.

Let's spend some time in tomorrow's conference call discussing Resource Priorities.

Thanks,
Jatinder

-----Original Message-----
From: Simon Pieters [mailto:simonp@opera.com] 
Sent: Tuesday, June 25, 2013 8:56 AM
To: public-web-perf@w3.org
Subject: [ResourcePriorities] Only specify lazyload on img

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

says

[[
The lazyload attribute can be specified on the following HTML elements capable of fetching resources:

audio
embed
iframe
img
link
object
script
svg
video
]]

Please remove all elements except img.

As far as I know, the stated use case that the lazyload attribute is intended to address is only about images. The solution should focus on addressing the stated use case and not immediately feature creap to everything you can think of.

Let's have a brief look at whether having lazyload makes sense on the listed elements:

audio
video

These already have the preload="" attribute to control loading. The states are "auto", "metadata" and "none". On the face of it, it seems reasonable to also support "lazy" where it acts like "none" if the element is outside the viewport and "metadata" or "auto" if it's visible or is soon about to be visible. However, I think it would be better to start small and wait until the lazyload attribute has proven its merits on the img element before extending it to media elements.

embed
iframe
object

These can create nested browsing contexts. It seems like it would cause various complications if these can be lazy-loaded. They are complicated as it is.

link

It has been proposed that an attribute be added to stylesheet link to not block execution of scripts. However, the spec doesn't address that.  
"lazyload" also seems like the wrong semantic -- a link element is always invisible, and the proposed attribute is more like <script async> i.e.  
fetch now but don't block scripts.

script

This already has means to control when the script is executed (async and defer). Since scripts are invisible, lazyload seems like the wrong semantic. If the author wishes to load a script at a certain point, that is possible by creating and inserting a script at that point.

svg

This doesn't even fetch anything.

--
Simon Pieters
Opera Software

Received on Tuesday, 25 June 2013 18:36:15 UTC