Contact emails
scli...@chromium.org, be...@chromium.org, rajen...@chromium.org
Explainer
https://github.com/scott-little/lazyload
https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit
Spec
Spec change pull request: https://github.com/whatwg/html/pull/3752
Tag review: https://github.com/w3ctag/design-reviews/issues/361 (started recently, since we initially didn't think one was necessary, but better late than never).
Summary
Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset).
Deferred content will start loading in when the user scrolls the viewport within a particular distance of it. The load-in distance depends on factors like the speed of the network, tuned such that content is typically finished loading in by the time it becomes visible.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, all platforms will support lazily loading <img> and <iframe> elements with loading="lazy" set on them.
On Android Chrome with Data saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good candidates for lazy loading (according to heuristics). Setting loading="eager" on the image or iframe element will still prevent it from being lazily loaded though.
Risks
Interoperability and Compatibility
Firefox: No public signals
Edge: No public signals
Safari: Some public support
A WebKit developer has mentioned that Apple is interested in this kind of feature and is a reviewer on the LazyLoad spec pull request.
Web developers: Positive signals
A thread on WICG about lazy loading images
Elements deferred by LazyLoad will have their onload event delayed until they load in later on (e.g. after the user scrolls nearby), which could happen after the document's onload event fires.
Ads that count impressions when an ad is loaded instead of when the ad is seen by the user (i.e. becomes visible in the viewport) could see their impression counts change for ads are currently often loaded but not seen. Users will still see lazily loaded ads just as often as they would have otherwise though.
Other compatibility risks are listed in the design doc.
Ergonomics
Deferring images makes use of the image replacement feature in Blink in order to avoid reflows when images load in later.
Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will currently show any deferred images or frames as blank boxes if they haven't loaded in yet, but this is something that will be fixed after the initial shipping (e.g. by forcing all deferred content to load in immediately, and block the print/save operation on that). More details here.
Activation
Sites can use LazyLoad by setting the attribute loading="lazy" on images or iframes. Sites can also prevent image or iframe elements from being lazily loaded by setting loading="eager" on them. Sites can detect LazyLoad support in JavaScript by checking if the "loading" property is defined, in a similar way to how many other features can be detected, e.g.:
if ('loading' in HTMLImageElement.prototype) { … }
We're also exploring adding a Client Hint for LazyLoad support.
Debuggability
When images are being lazily loaded, a message is logged to the console. No other DevTools integration is currently planned.
Demo
At time of writing, LazyLoad can be experimented with by going to chrome://flags and turning on both "Enable lazy frame loading" and "Enable lazy image loading". This will turn on LazyLoad for images and iframes marked loading="lazy", plus those marked loading="auto" or without any "loading" attribute set that are well suited to being lazily loaded, similar to how the feature will behave for Android Chrome Data Saver users when launched.
Is this feature fully tested by web-platform-tests?
The tests are in progress right now, but it will be fully tested by web-platform-tests.
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=709494
Entry on the feature dashboard
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e70588ac-6395-42f2-94f0-40daafff8ec8%40chromium.org.
Contact emails
scli...@chromium.org, be...@chromium.org, rajen...@chromium.org
Explainer
https://github.com/scott-little/lazyload
https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit
Spec
Spec change pull request: https://github.com/whatwg/html/pull/3752
Tag review: https://github.com/w3ctag/design-reviews/issues/361 (started recently, since we initially didn't think one was necessary, but better late than never).
Summary
Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset).
Deferred content will start loading in when the user scrolls the viewport within a particular distance of it. The load-in distance depends on factors like the speed of the network, tuned such that content is typically finished loading in by the time it becomes visible.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, all platforms will support lazily loading <img> and <iframe> elements with loading="lazy" set on them.
On Android Chrome with Data saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good candidates for lazy loading (according to heuristics). Setting loading="eager" on the image or iframe element will still prevent it from being lazily loaded though.
Risks
Interoperability and Compatibility
Firefox: No public signals
Edge: No public signals
Safari: Some public support
A WebKit developer has mentioned that Apple is interested in this kind of feature and is a reviewer on the LazyLoad spec pull request.
Web developers: Positive signals
A thread on WICG about lazy loading images
Elements deferred by LazyLoad will have their onload event delayed until they load in later on (e.g. after the user scrolls nearby), which could happen after the document's onload event fires.
Ads that count impressions when an ad is loaded instead of when the ad is seen by the user (i.e. becomes visible in the viewport) could see their impression counts change for ads are currently often loaded but not seen. Users will still see lazily loaded ads just as often as they would have otherwise though.
Other compatibility risks are listed in the design doc.
Ergonomics
Deferring images makes use of the image replacement feature in Blink in order to avoid reflows when images load in later.
Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will currently show any deferred images or frames as blank boxes if they haven't loaded in yet, but this is something that will be fixed after the initial shipping (e.g. by forcing all deferred content to load in immediately, and block the print/save operation on that). More details here.
Activation
Sites can use LazyLoad by setting the attribute loading="lazy" on images or iframes. Sites can also prevent image or iframe elements from being lazily loaded by setting loading="eager" on them. Sites can detect LazyLoad support in JavaScript by checking if the "loading" property is defined, in a similar way to how many other features can be detected, e.g.:
if ('loading' in HTMLImageElement.prototype) { … }
Debuggability
When images are being lazily loaded, a message is logged to the console. No other DevTools integration is currently planned.
Demo
At time of writing, LazyLoad can be experimented with by going to chrome://flags and turning on both "Enable lazy frame loading" and "Enable lazy image loading". This will turn on LazyLoad for images and iframes marked loading="lazy", plus those marked loading="auto" or without any "loading" attribute set that are well suited to being lazily loaded, similar to how the feature will behave for Android Chrome Data Saver users when launched.
Is this feature fully tested by web-platform-tests?
The tests are in progress right now, but it will be fully tested by web-platform-tests.
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=709494
Entry on the feature dashboard
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rV_uNeekijVoSezJXc5nf4RKTmHk4ZMe6tvosy9amtQQQ%40mail.gmail.com.
Non-owner LGTM. Very very excited to see this work finally shipping! Scott, did we resolve if the implementation we're shipping..
(1) Has <picture> support wired up? We had discussed this with Yoav but unsure of current status.
(2) Whether developers are likely to see double fetch entries in the DevTools network panel? I recall we fetch the first 2KB of images on page load & the remaining bytes when they're about to see the image.
For (2) I guess we can also wait and see how the discussion in https://github.com/w3c/resource-timing/issues/205 evolves.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e70588ac-6395-42f2-94f0-40daafff8ec8%40chromium.org.
I share the general excitement, and think this feature is long overdue on the web. Thanks for working on this! :)
On Sat, Apr 6, 2019 at 12:40 AM Scott Little <scli...@chromium.org> wrote:
Contact emails
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
I have just tested this new lazy load experimental feature in Chrome (73.0.3683.103).I found an issue with the loading of css background images.Example: https://take.ms/fUtNJThe lazy loading breaks the page navigation / dropdown menu, as certain background images are suppressed: https://take.ms/GQzX4
Is there a way to pass the loading attribute "eager" also to css background images?
Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12fa06d1-9e20-4e3f-9be9-3b4d9971bda0%40chromium.org.
const img = new Image(); img.src = url; img.onload = () => { // ready! };
const img = new Image(); img.src = url; await img.decode(); // ready!
const div = document.createElement('div'); div.style.display = 'none'; document.body.append(div); const img = new Image(); img.src = url; div.append(img); img.onload = () => { div.style.display = 'block'; };
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e356d343-8d56-4b2b-a83f-045dced55598%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e356d343-8d56-4b2b-a83f-045dced55598%40chromium.org.
With the "enable lazy images" flag enabled, I spotted some bugs with SVG files referenced as background images in an external CSS file.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jxiJvQc-gVg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1086cd65-675f-4b5c-af60-90f6b3e08126%40chromium.org.
Another concern of mine is that if Chrome/others ship lazy loading below-the-fold content by default, this may greatly reduce the need for devs to explicitly write `loading=lazy`, but I realize the attribute is a good way to start with an opt-in model. I just wonder if eventually we'll end up with this "extra" attribute developers won't really be motivated to use because by omitting it entirely, they get the same effect.
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:1. Improved web platform tests coverage
2. Rounding out the spec concerns.
I'll be working with Ben and Scott on some of the remaining specification work.
On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:1. Improved web platform tests coverageLast I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.
2. Rounding out the spec concerns.I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25bcef1c-09eb-4f9d-8118-898d0ea1b179%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rV_uNeekijVoSezJXc5nf4RKTmHk4ZMe6tvosy9amtQQQ%40mail.gmail.com.
On Sat, May 18, 2019 at 6:36 AM Dominic Farolino <domfa...@gmail.com> wrote:I'll be working with Ben and Scott on some of the remaining specification work.That's great to hear! Thank you!! :)
On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:1. Improved web platform tests coverageLast I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.Looking forward to it!2. Rounding out the spec concerns.I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.If we're going that route, maybe we can also be explicit about image which have onload/onerror events attached to them, and make sure they are eagerly loaded as well in auto mode?I think that would help alleviate many of the compatibility concerns. (although the page's onload event can still rely on the image data being there in some weird ways)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25bcef1c-09eb-4f9d-8118-898d0ea1b179%40chromium.org.
On Saturday, May 18, 2019 at 4:57:15 PM UTC+9, Yoav Weiss wrote:On Sat, May 18, 2019 at 6:36 AM Dominic Farolino <domfa...@gmail.com> wrote:I'll be working with Ben and Scott on some of the remaining specification work.That's great to hear! Thank you!! :)
On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:1. Improved web platform tests coverageLast I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.Looking forward to it!2. Rounding out the spec concerns.I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.If we're going that route, maybe we can also be explicit about image which have onload/onerror events attached to them, and make sure they are eagerly loaded as well in auto mode?I think that would help alleviate many of the compatibility concerns. (although the page's onload event can still rely on the image data being there in some weird ways)Hmm, could you outline the compat concerns you have in mind that this would mitigate, that would not be addressed by "ensuring images/iframes created by script are always eagerly-loaded)? I feel like if a user has added onload/onerror events to an image far below-the-fold, we'd be penalizing them by making the image non-lazy-loadable, where it may be reasonable for a developer to want onload/onerror events on images that may not load for a while, but I may be missing something?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ab1ac2-2682-4039-9c25-16239afe8c0e%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ab1ac2-2682-4039-9c25-16239afe8c0e%40chromium.org.
Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed relative to the most up-to-date value of the outer document's URL.Anne, currently reviewing the PR, believes this may be problematic.
He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL at that time. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which may be best, I'm happy to hear them.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05b6e854-2873-4e26-b89b-9fa167d17f3f%40chromium.org.
Thanks for the update!On Tue, Jul 16, 2019 at 9:19 AM Dominic Farolino <domfa...@gmail.com> wrote:Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed relative to the most up-to-date value of the outer document's URL.Anne, currently reviewing the PR, believes this may be problematic.He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL at that time. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which may be best, I'm happy to hear them.Seems like the concern is that decisions like the base URL may be racy in the current model, depending on *when* the user scrolled down. Is that exclusive to iframes? (e.g. seems like the base URL should also be relevant for images with relative URLs)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05b6e854-2873-4e26-b89b-9fa167d17f3f%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54dc2866-0bf2-41a7-9eb6-0eb87b33f6fc%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_bMpZGCOHgdUiKSarM7QfoD5pr6UWECuc7rkPELtJ2gw%40mail.gmail.com.
This is looking like it's about ready to ship an initial version to me. I see there's still some debate around some precise semantics / timing, and we can expect some of those details may change as part of finalizing the spec PR and tag review. But, for an opt-in feature, those all seem like changes that will be easy to make post-ship.A few things I see that still probably block shipping:
- Confirm all the WPTs are passing. From the WPT dashboard, it looks like the feature isn't yet enabled by --enable-experimental-web-platform-features? If so, that's a shame (great way to get additional testing and test results that are widely visible)
- Ping the tag review indicating we now believe the design is solid and are planning on shipping an initial version (but we are, of course, still open to changes in the details).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54dc2866-0bf2-41a7-9eb6-0eb87b33f6fc%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cc89816-a791-4e66-b0c1-de788082ec93%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9p93W-p_YiQJZF_4w7jV7uRcp2L_ZBNB4LtMWbBvGgRA%40mail.gmail.com.
On 7/26/19 7:47 PM, Rick Byers wrote:
> Thanks.
>
> LGTM1 to ship once the remaining WPTs land.
>
> Obviously there's still likely to be some tweaks to the precise semantics and spec text, but the API shape is very simple and seems likely to be
> stable now. Being an opt-in feature,
It is not an opt-in feature, at least not per the latest PR.
So shipping the feature is rather risky. It could let browsers to handle page loads in various different ways, depending on the heuristics they want
to do with 'auto': "Indicates a preference for the user agent to determine the fetching strategy (the default)."
-Olli
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fafc269d-cb20-436a-9523-0afc3542cf50%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.