Closed Bug 947427 (lazyload) Opened 6 years ago Closed Last month

Implement the lazyload attribute

Categories

(Core :: DOM: HTML Parser, enhancement, P3)

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1542784

People

(Reporter: nathanael.jones, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: parity-chrome, Whiteboard: [geckoview:p2])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

I added 4 images to a page; with the first two containing the 'lazyload' attribute. http://fiddle.jshell.net/CSE98/3/show/light/


Actual results:

(per the network tab) Images were requested in the order they appear in the HTML, lazyload attribute was ignored.


Expected results:

The first two images should have been requested last.

Even the simplest implementation of resource priorities support (such as skipping speculative parsing on the element) would enable the development of usable polyfills for current responsive image proposals.

Standardization of a responsive image specification has so far been fruitless, as we cannot offer web developers sane polyfills for any proposal that do not cause multiple requests and negate the benefit. The best current technique is to place the <img> tag within a <noscript> element and duplicate all <img> attributes on the <noscript> element itself (as IE 6/7/8 cannot access noscript contents). This causes and 80-130% markup increase. Human error during attribute duplication also causes browser-specific failures, but duplication cannot currently be avoided without sacrificing accessibility and graceful degradation.

Take a look at Slimmage.js and picturefill to see the current implications, and how critical resource priorities support is to real progress with responsive image solutions.
I'm not entirely sure about the Component. Feel free to change it as felt appropriate.
Status: UNCONFIRMED → NEW
Component: General → DOM: Core & HTML
Ever confirmed: true
Summary: Implement basic Resource Priorities support: images with 'lazyload' attribute load last. → Implement the lazyload attribute
Actually, this happens in the HTML parser (or more precisely the tokenizer), since it needs to happen before creating the DOM nodes.
Component: DOM: Core & HTML → HTML: Parser
Would it be enough to just use HTTPChannel's priority here?
lazyload could use http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/nsISupportsPriority.idl?force=1#28
At least we'd start the higher/normal priority requests before those lower priority ones.
(In reply to Nathanael Jones from comment #0)
> Take a look at Slimmage.js and picturefill to see the current implications,
> and how critical resource priorities support is to real progress with
> responsive image solutions.

While it would be easy to make the HTML parser not to do preloads for elements that have the lazyload attribute, it seems wrong to introduce a feature in order to enable the development of polyfills for another feature instead of just implementing the other feature directly.

It's not clear to me if this bug asks us to implement the lazyload  attribute as specified (bug summary) or if this bug asks us to turn off preloads when the lazyload attribute is present (bug description).
(In reply to Henri Sivonen (:hsivonen) from comment #4)
> While it would be easy to make the HTML parser not to do preloads for
> elements that have the lazyload attribute, it seems wrong to introduce a
> feature in order to enable the development of polyfills for another feature
> instead of just implementing the other feature directly.
> 
> It's not clear to me if this bug asks us to implement the lazyload 
> attribute as specified (bug summary) or if this bug asks us to turn off
> preloads when the lazyload attribute is present (bug description).
I didn't find any bug about implementing the lazyload attribute. This one was the closest I found, so I decided to make the summary more straightforward. If I understand correctly, implementing the lazyload attribute will solve the reporter's problem (admittedly maybe not in the most appropriate way, but that's the reporter's problem, not related to the implementation of @lazyload)
(In reply to Henri Sivonen (:hsivonen) from comment #4)
> (In reply to Nathanael Jones from comment #0)
> > Take a look at Slimmage.js and picturefill to see the current implications,
> > and how critical resource priorities support is to real progress with
> > responsive image solutions.
> 
> While it would be easy to make the HTML parser not to do preloads for
> elements that have the lazyload attribute, it seems wrong to introduce a
> feature in order to enable the development of polyfills for another feature
> instead of just implementing the other feature directly.
> 
> It's not clear to me if this bug asks us to implement the lazyload 
> attribute as specified (bug summary) or if this bug asks us to turn off
> preloads when the lazyload attribute is present (bug description).

Henri, the problem is that everyone needs a different feature. There is no *feature* to solve everyone's use case. The proposals that come close require gargantuan volumes of markup and html pre-processors in order to calculate pixel values correctly. And even then, they do not permit developers to move image layout and formatting into CSS; consequently, developers can only size images relative to the viewport, rending reflow layouts impossible to support. 

In the strictest sense, speculative parsing is itself a bug. Developers were not offered any way around that bug, despite scenarios such as responsive images, where the consequences can affect page size by 4-15MB. Speculative parsing is a fantastic speed improvement - when it doesn't download an additional 15MB of unused imagery.

While the Resource Priorities spec doesn't directly mention speculative parsing, it's generally the only thing blocking a responsive images solution on any given browser.
From http://www.w3.org/TR/resource-priorities/ :
"Beware. This specification is no longer in active maintenance and the Web Performance Working Group does not intend to maintain it further."

(I tried to dig in web-perf archives, but haven't found why and what is the replacement if any).

WONTFIX?
"This specification is no longer maintained and has been abandoned. Folks should look at resource hints instead. http://www.w3.org/TR/resource-hints/ "
Chrome 70 now has support for a lazyload="auto/on/off" attribute behind a flag: https://www.chromestatus.com/feature/5641405942726656
Chrome Platform Status for the proposed lazyload attribute:
https://www.chromestatus.com/feature/5641405942726656

Chrome Bug for the proposed lazyload attribute:
https://bugs.chromium.org/p/chromium/issues/detail?id=869492

See also:

Blink LazyLoad Design Doc:
https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit

LazyLoad is a Chrome optimization that defers loading below-the-fold images and certain third-party iframes on the page until the user scrolls near them, which reduces data usage, speeds up page loads, and reduces memory use.

Blink LazyFrames Design Doc:
https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit

The LazyFrames mechanism in Blink defers certain iframes from being loaded until the user scrolls near them, in order to save data, speed up the loading of other parts of the page, and reduce memory usage. It will be used as part of the LazyLoad feature.
Alias: lazyload
Keywords: parity-chrome
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Whiteboard: [geckoview:p2]
WICG for lazyload: https://github.com/whatwg/html/pull/3752 for iframes and img elements
Keywords: dev-doc-needed

According to this post and intent to ship, it will be unleashed in Chrome 75.

It might be better to have a new bug for the differently-named feature.

Type: defect → enhancement
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → DUPLICATE
Duplicate of bug: 1542784
You need to log in before you can comment on or make changes to this bug.