- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 26 Jun 2013 00:50:50 +0200
- To: James Simonsen <simonjam@google.com>
- Cc: Simon Pieters <simonp@opera.com>, public-web-perf <public-web-perf@w3.org>
On Tue, Jun 25, 2013 at 10:27 PM, James Simonsen <simonjam@google.com> wrote: > I'll note that this feature had enthusiastic support at Velocity. > > On Tue, Jun 25, 2013 at 8:56 AM, Simon Pieters <simonp@opera.com> wrote: >> >> >> 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. > > Fair enough. We've added things in level 2 specs before. It seems like a > minor case to omit for now. These also have the additional complication that <audio> is commonly never visible in the sense that an image is, so the question is when to start loading it. But both <audio> and <video> is however always visible in the sense that if they play audio that's something the user notices whatever the scroll position is. But in general lazyload for audio and video sounds like it could be very useful. One solution might be to automatically start loading if autoplay is set, or if play() is called. >> 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. > > > I'm more interested in the usefulness than the complexity. If a page has a > bunch flash players below the fold, it seems useful to skip initializing > them if the user never scrolls. I think the usefulness is there. It's up to > us to deal with the complexity. I generally agree. Though I'll warn that loading of browsing contexts is incredibly complicated, not fully understood by anyone I've ever met, most likely differs in important ways between all implementations, and the spec is unlikely to match anyone. Here be dragons! >> 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. > > Yeah, I'm not sure what the use case is on this one. I'd love to hear it if > someone has one. > >> 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. > > The point is that it doesn't block the load event. You can specify > everything in HTML, but not interfere with the critical path of the page > load. An example use would be analytics, where it doesn't need to obstruct > the page load and can load and run at an arbitrarily later time. If all lazyload does for script is to make it not the script not block the "load" event, then it doesn't seem like 'lazyload' is the right attribute. I.e. it seems like a bad for 'lazyload' to mean different things on different elements. >> svg >> >> This doesn't even fetch anything. > > Maybe not that specifically, but there are a bunch of things in SVG that > could use it. I think they have their own <script> tag for instance. Indeed, but we should look at those separately. Many of the above caveats apply to the various svg features too. / Jonas
Received on Tuesday, 25 June 2013 22:51:47 UTC