[webkit-dev] Lazy loading

[Dominic Farolino]

*Maciej wrote:*

- 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


Just to circle back to this, the current spec PR does not include the
"auto" attribute, so there is no need for any Feature/Document policies to
control the default image- or frame-loading. The `loading` attribute has
two values "lazy" and "eager", and the missing/invalid-value default is
"eager".

Long-term, Chrome is interested in exploring making the default
"lazy". However, we're thinking a good intermediate step is in the future,
add "auto" back to the spec and introduce a Document or Feature Policy that
allows developers to specify that "auto" == "lazy". Then over time, we may
consider simply making the default "lazy". There has been
discussion/proposals for image- and frame-policies [1] [2]. There has not
been many updates to the proposals, so I am not sure how reliable the
current text is. Furthermore, there is a tracking issue for Chrome [3]
which covers some implementation discussion for these policies, however it
too seems stalled.

FYI Chrome currently ships the "auto" attribute, but it is treated as
"eager" unless the user has opted into Lite mode, as Thomas mentioned.

[1]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-image-default-eager.md
[2]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-frame-default-eager.md
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=949683
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Scott Little]

> 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.

Cheers,
- Scott

On Mon, Oct 28, 2019 at 8:08 PM Rob Buis  wrote:

> > 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?
>
> Regards,
>
> Rob.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Rob Buis]

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?


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Rob Buis]

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  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.

Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Scott Little]

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.

Cheers,
- Scott
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 3:08 PM, Rob Buis  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 `` 
and `` 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 `` and 
`` 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] 
[2] 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Rob Buis]

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.


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> 
> Hi,
> 
> I made a lazy image loading prototype earlier this year 
> (https://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?

> 
> 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.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Thomas Steiner]

On Mon 28. Oct 2019 at 20:02 Simon Fraser  wrote:

> > On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> >
> > Hi,
> >
> > I made a lazy image loading prototype earlier this year (
> https://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:
https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html.
You can contact the blog post authors for more background if need be.


>
> >
> > 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
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Simon Fraser]

> On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> 
> Hi,
> 
> I made a lazy image loading prototype earlier this year 
> (https://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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Lazy loading

[Rob Buis]

Hi,

I made a lazy image loading prototype earlier this year 
(https://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.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev