Lazy loading

# Rob Buis (a day ago)

I made a lazy image loading prototype earlier this year (bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it up into reviewable patches. The main implementation part landed recently so I am wondering about the next steps.

One thing left to do for sure is cleaning up/adding tests. For one there are tests in http/tests/lazyload which can just be WPT tests, so I'll work in this area for sure. As usual, while adding new tests bugs may show up and more patches will be needed.

Another possible task is implementing metadata fetch, but it makes the code more complex and chromium has backtracked from it.

Changing the behavior of loading=auto to make lazy loading the default seems risky and should possibly only be done when lazy image loading is deemed stable enough.

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it.

A related task is implementing lazy loading for iframe's, I took a quick look and this looks like similar work to lazy image loading, but should be much easier to implement now the building blocks are there.

Finally there is the task of setting threshold viewport distance values for triggering deferred loads. I only have access to iOS simulator, so I wonder if that is something Apple could help with?

I do not have a strong preference among these tasks. Thoughts? Cheers,

Rob.

P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat with me there about lazy loading.

Contact us to advertise here
# Simon Fraser (a day ago)

On Oct 28, 2019, at 11:39 AM, Rob Buis <rbuis at igalia.com> wrote:

Hi,

I made a lazy image loading prototype earlier this year (bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it up into reviewable patches. The main implementation part landed recently so I am wondering about the next steps.

One thing left to do for sure is cleaning up/adding tests. For one there are tests in http/tests/lazyload which can just be WPT tests, so I'll work in this area for sure. As usual, while adding new tests bugs may show up and more patches will be needed.

Another possible task is implementing metadata fetch, but it makes the code more complex and chromium has backtracked from it.

Changing the behavior of loading=auto to make lazy loading the default seems risky and should possibly only be done when lazy image loading is deemed stable enough.

Agreed. Is there any compat data from other browsers?

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it.

A related task is implementing lazy loading for iframe's, I took a quick look and this looks like similar work to lazy image loading, but should be much easier to implement now the building blocks are there.

I think this one has the highest potential to give big page loading gains, especially if we can get this one turned on by default (or maybe for cross-origin frames), so I suggest working on this.

Do we have any data from other browsers to know whether enabling lazy-loading iframe by default breaks the web?

Finally there is the task of setting threshold viewport distance values for triggering deferred loads. I only have access to iOS simulator, so I wonder if that is something Apple could help with?

I would be happy to help.

I do not have a strong preference among these tasks. Thoughts? Cheers,

Rob.

P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat with me there about lazy loading.

See you there!

Simon

# Thomas Steiner (a day ago)

On Mon 28. Oct 2019 at 20:02 Simon Fraser <simon.fraser at apple.com> wrote:

On Oct 28, 2019, at 11:39 AM, Rob Buis <rbuis at igalia.com> wrote:

Hi,

I made a lazy image loading prototype earlier this year ( bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it up into reviewable patches. The main implementation part landed recently so I am wondering about the next steps.

One thing left to do for sure is cleaning up/adding tests. For one there are tests in http/tests/lazyload which can just be WPT tests, so I'll work in this area for sure. As usual, while adding new tests bugs may show up and more patches will be needed.

Another possible task is implementing metadata fetch, but it makes the code more complex and chromium has backtracked from it.

Changing the behavior of loading=auto to make lazy loading the default seems risky and should possibly only be done when lazy image loading is deemed stable enough.

Agreed. Is there any compat data from other browsers?

>

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it.

A related task is implementing lazy loading for iframe's, I took a quick look and this looks like similar work to lazy image loading, but should be much easier to implement now the building blocks are there.

I think this one has the highest potential to give big page loading gains, especially if we can get this one turned on by default (or maybe for cross-origin frames), so I suggest working on this.

Do we have any data from other browsers to know whether enabling lazy-loading iframe by default breaks the web?

We on the Chrome team have rolled this out to Lite Mode users recently and, as far as I can tell, haven’t seen any breakage: blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html. You can contact the blog post authors for more background if need be.

# Maciej Stachowiak (a day ago)

On Oct 28, 2019, at 11:39 AM, Rob Buis <rbuis at igalia.com> wrote:

Hi,

I made a lazy image loading prototype earlier this year (bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it up into reviewable patches. The main implementation part landed recently so I am wondering about the next steps.

One thing left to do for sure is cleaning up/adding tests. For one there are tests in http/tests/lazyload which can just be WPT tests, so I'll work in this area for sure. As usual, while adding new tests bugs may show up and more patches will be needed.

Another possible task is implementing metadata fetch, but it makes the code more complex and chromium has backtracked from it.

Changing the behavior of loading=auto to make lazy loading the default seems risky and should possibly only be done when lazy image loading is deemed stable enough.

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it.

Is there a way for content authors to opt in/out (depending on the default), or does this just always follow what the default lazy loading setting is?

# Rob Buis (a day ago)

On 10/28/19 9:07 PM, Maciej Stachowiak wrote:

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it. Is there a way for content authors to opt in/out (depending on the default), or does this just always follow what the default lazy loading setting is?

From reading the chromium code, it seems to use a combination of feature policy and the loading attribute to decide whether to enable CSS backgrounds lazy loading or not. Hopefully a chromium developer can confirm.

# Maciej Stachowiak (21 hours ago)

On Oct 28, 2019, at 3:08 PM, Rob Buis <rbuis at igalia.com> wrote:

On 10/28/19 9:07 PM, Maciej Stachowiak wrote:

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it. Is there a way for content authors to opt in/out (depending on the default), or does this just always follow what the default lazy loading setting is?

From reading the chromium code, it seems to use a combination of feature policy and the loading attribute to decide whether to enable CSS backgrounds lazy loading or not. Hopefully a chromium developer can confirm.

Per the PR for lazy loading[1], the loading attribute applies only to <img> and <iframe> elements. Most CSS background images are not on either of these specific elements. I can imagine one of the following:

  • Chromium has a nonstandard extension beyond what is in the PR to make loading a global/superglobal attribute (in which case we probably shouldn’t implement that until spec’d)
  • The attribute only applies to CSS backgrounds on specifically the <img> and <iframe> elements, which would be weirdly limited, and also would be a nonstandard extension to the PR
  • CSS backgrounds (and other CSS images?) don’t have an individual override, only the global override via Feature Policy.

This raises two further concerns though:

  • Lazy loading for CSS images is not specified in the lazy loading PR[1]. Is it specified elsewhere, or is it a nonstandard Chromium extension?
  • I couldn’t find a spec for a lazy loading feature policy either, and the Chrome Platform Status page for it gives the status as “removed”[2] so this too might be a nonstandard thing. Or maybe there is a newer (Doesn’t look like the feature policy aspect is in your patch though.)

I hope I am not being too nitpicky. I do think this is a great feature. I just want to make sure we’re cautious about the line between implementing standards-track stuff vs copying things from Chromium that are nonstandard or unspecified (so far).

It’s also really worrisome if Chrome implemented semantics for the “loading” attribute beyond what is in the PR, as that will make interop a challenge.

Regards, Maciej

[1] whatwg/html#3752 [2] www.chromestatus.com/feature/5641405942726656

# Scott Little (21 hours ago)

Regarding lazily loading CSS background images, Chromium determines whether or not to lazily load CSS background images according to the default lazy loading behavior, and isn't directly controlled by the "loading" attribute. There are some heuristics involved, e.g. background images inside an iframe that was itself lazily loaded are loaded eagerly for performance reasons, but those heuristics are just part of the default lazy loading behavior.

# Rob Buis (17 hours ago)

Apologies, it seems I spread some misinformation about CSS background lazy loading, which Scott rectified.

On 10/29/19 12:36 AM, Maciej Stachowiak wrote:

On Oct 28, 2019, at 3:08 PM, Rob Buis <rbuis at igalia.com> wrote:

On 10/28/19 9:07 PM, Maciej Stachowiak wrote:

Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in the prototype but I don't think there are many tests for it. Is there a way for content authors to opt in/out (depending on the default), or does this just always follow what the default lazy loading setting is? From reading the chromium code, it seems to use a combination of feature policy and the loading attribute to decide whether to enable CSS backgrounds lazy loading or not. Hopefully a chromium developer can confirm.

  • I couldn’t find a spec for a lazy loading feature policy either, and the Chrome Platform Status page for it gives the status as “removed”[2] so this too might be a nonstandard thing. Or maybe there is a newer (Doesn’t look like the feature policy aspect is in your patch though.)

The prototype was done in February. I think Youenn was starting implementation of feature policy at the same time or maybe later. Then later I did not really touch CSS background lazy loading again, since there were a lot of other issues instead to address, one of them being the spec was changing over time. Will be happy with addressing it now, though I am not sure how impactful it will be for users compared to lazy image loading.

I hope I am not being too nitpicky. I do think this is a great feature. I just want to make sure we’re cautious about the line between implementing standards-track stuff vs copying things from Chromium that are nonstandard or unspecified (so far).

Understood.

# Rob Buis (17 hours ago)

Regarding lazily loading CSS background images, Chromium determines whether or not to lazily load CSS background images according to the default lazy loading behavior, and isn't directly controlled by the "loading" attribute. There are some heuristics involved, e.g. background images inside an iframe that was itself lazily loaded are loaded eagerly for performance reasons, but those heuristics are just part of the default lazy loading behavior.

Scott, thanks for the clarification! Are there plans to better specify CSS background images lazy loading?

# Scott Little (an hour ago)

Are there plans to better specify CSS background images lazy loading?

There aren't currently any plans to add lazy CSS background images to a spec, or at least no plans that I know of right now.

Right now in Chromium, the default lazy loading behavior is essentially based on whether or not the user has opted into Lite Mode (aka Data Saver), so we've mostly been treating CSS background image lazy loading as kind of an extra intervention or optimization to help these Lite Mode users save more data.

Chromium code currently decides whether or not to lazily load CSS background images according to the default lazy loading behavior, but if in the future Chromium ever turns on automatic lazy loading as the default behavior for non-Lite Mode users, we'd first either want lazy CSS background images to be part of the spec, or we'd separate out lazy CSS background images to be restricted to Lite Mode.

Want more features?

Request early access to our private beta of readable email premium.