- From: James Simonsen <simonjam@google.com>
- Date: Tue, 25 Jun 2013 13:27:09 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAPVJQinwAbJ9_-HjAOKG=T7x57sm7LwJs48fvQbDNA=sarkxDw@mail.gmail.com>
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<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. > 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. > > 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. > 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. James
Received on Tuesday, 25 June 2013 20:27:36 UTC