Feature Policy: lazyload

[ehsan-karamad]

Proposing a new feature policy for lazy-loading which will overwrite the default or specified behavior of lazyload attribute for <iframe> and <img>. The proposed name for the feature is lazyload.

The lazyload attribute (for an <iframe> or <img>) takes on three values of auto (decision of lazy-loading is deferred to the user agent), on (the contents will be loaded lazily), off (the contents will not be loaded lazily).

The proposed lazyload feature is a parameterized feature which takes one of the three values of:

• auto: the default behavior of lazyload attribute is not altered (user agent decides) .
• off: the default behavior of lazyload is set to off.
  For example, if the site www.example.com sets its header policy to Feature Policy: lazyload 'self'(off), then

 <iframe src="https://www.example.com/a" lazyload="on"></iframe>

will still load the contents lazily due to the defined attributes, but

<iframe src="https://www.example.com/b"></iframe>

will not load the contents lazily since the feature is set to off by default.

• force: ignores the value of lazyload attribute and enforces it to on for all <iframe> and <img> .
  For example, if a site sets its header policy to Feature Policy: lazyload *(force) then all <iframe>'s and <img>'s from all domains will be loaded lazily. For example in

<iframe src="http://www.example.com/" lazyload="off"></iframe>

the provided attributed is ignored and the contents will be loaded lazily due to policy enforcement. Also, since the lazyload attribute setting is in violation of the lazyload feature, such a usage may trigger a violation error.

The feature can also be set through container policies, for instance:

<iframe allow="lazyload *(force)" src="https://www.example.com" lazyload="off"></iframe>

which will enforce lazy loading for all domains. This would include https://www.example.com.

[Malvoz]

Just to clarify, I believe you missed the single quotes for the self and none values. And I would assume we set (auto|off|force) flags outside the single quotes? e.g. Feature Policy: lazyload 'self'(force) and the all (*) directive like so: Feature Policy: lazyload *(force).

[ehsan-karamad]

Thanks you are right. I fixed the missing single quotes for self.

[alvarotrigo]

Any way to detect whether the browser supports this feature or not?
So we can use other lazy load libraries in case it doesn't ?

[triblondon]

Doesn't this feature have a really confusing name? I'm reading https://github.com/w3c/webappsec-feature-policy/blob/master/policies/lazyload.md, where it says:

Feature Policy: lazyload 'self' https://example.com
would not allow synchronous loading for any <iframe> or (that is not yet in the viewport) from origins other than 'self' or https://example.com.

So, wait, if I apply the lazyload policy to example.com, then everything except example.com enforces lazy loading? I read it like 6 times and I can't see how that makes any sense...

Suggestions: greedy-load, preload-offscreen

[ehsan-karamad]

Any way to detect whether the browser supports this feature or not?
So we can use other lazy load libraries in case it doesn't ?

I think on Chrome 74 with "Experimental Web Platform" flag off, |el.lazyload| would return undefined. However, it would return auto if the flag is on.

[ehsan-karamad]

Doesn't this feature have a really confusing name?

I agree the name is confusing; it is supposed to suggest the full control over the lazyload attribute, i.e., of disabled you cannot do certain things. Another alternative we are thinking is the termeager-loading. I like the preload-offscreen as well since it is very descriptive of what the policy does.

I'm reading https://github.com/w3c/webappsec-feature-policy/blob/master/policies/lazyload.md, where it says:
Feature Policy: lazyload 'self' https://example.com
would not allow synchronous loading for any <iframe> or (that is not yet in the viewport) from origins other than 'self' or https://example.com.

So, wait, if I apply the lazyload policy to example.com, then everything except example.com enforces lazy loading? I read it like 6 times and I can't see how that makes any sense...

Suggestions: greedy-load, preload-offscreen

So, this feature is about the full right to use the lazyload attribute (and essentially the off state) on <img> and <iframe> elements. This means if the feature is disabled for an origin, then the origin cannot avoid lazyloading some content by setting the lazyload attribute value to off. If they did there will be enforcement (i.e., off changes to auto and browser decides what is best to do) and a policy violation report is generated.

For the specific example, if a website would define

Feature Policy: lazyload http://example.com

then any embedded content from http://example.com is allowed to use lazyload=off on its own <img> and <iframe> elements. However if the website embeds a http://foo.com which tries to do that they would end up violating the feature (e.g., lazyload enforced and a violation report is generated).

[ehsan-karamad]

Closed by accident :).

[triblondon]

So, this feature is about the full right to use the lazyload attribute (and essentially the off state) on <img> and <iframe> elements. This means if the feature is disabled for an origin, then the origin cannot avoid lazyloading some content by setting the lazyload attribute value to off. If they did there will be enforcement (i.e., off changes to auto and browser decides what is best to do) and a policy violation report is generated.

Yes, I understand that, but that's because I've read it six times :-) I really hope we can rename. eager-loading would work but sounds a bit too positive, so I would worry that people would throw it in thinking it sounded like a best practice. If you like preload-offscreen that sounds like a good option, as long as the semantics of the 'lazyload' attribute continue to be about viewport intersection, which is explicit in the naming of 'preload-offscreen' but not in 'lazyload'.

[ehsan-karamad]

There is a PR which would rework and rename the proposed lazyload policy. The new policy modifies the default/auto behavior of the loading attribute. The new name is loading-frame-default-eager and by turning it off, the <iframe>s inside the document will not load eagerly unless they have loading="eager" explicitly set. A similar policy should be proposed for <img>.

[triblondon]

loading="eager"? Not allow="loading-frame-default-eager *"?

[Malvoz]

@ehsan-karamad

Both the loading-frame-default-eager.md and loading-image-default-eager.md documents seem to be missing some sentencing in the "What does this mean" section:

With the loading-frame-default-eager policy, developers could prioritize the loading of different inline frames on a web page. This however could become a cumbersome process and not quite scalable for larger web sites; specially given that applying the attribute is origin-agnostic. The proposed policy aims to resolve this issue by changing a browser's default decision for loading behavior.

I think before the sentence: "This however could become a cumbersome process [...]" it should be explained that (e.g) "Developers may use the loading attribute to specify the loading behavior of an {image|iframe}.".

Is that correct? If so, I can PR unless you want to do it.

[ehsan-karamad]

@ehsan-karamad

Both the loading-frame-default-eager.md and loading-image-default-eager.md documents seem to be missing some sentencing in the "What does this mean" section:

With the loading-frame-default-eager policy, developers could prioritize the loading of different inline frames on a web page. This however could become a cumbersome process and not quite scalable for larger web sites; specially given that applying the attribute is origin-agnostic. The proposed policy aims to resolve this issue by changing a browser's default decision for loading behavior.

I think before the sentence: "This however could become a cumbersome process [...]" it should be explained that (e.g) "Developers may use the loading attribute to specify the loading behavior of an {image|iframe}.".

Is that correct? If so, I can PR unless you want to do it.

Thanks for pointing this out. Yes. I believe this is would look better. Please send a PR and also have @clelland take a look.

[Malvoz]

@RGHuhn

Yes, as stated in https://github.com/w3c/webappsec-feature-policy/issues/193#issuecomment-484109871 the lazyload policy was changed, and divided into 2 policies, namely loading-image-default-eager and loading-frame-default-eager.

[domfarolino]

As @Malvoz mentioned, this policy has been split in two, so can this be closed? Also, I'm curious as to the reasoning for splitting this into image- and frame-policies in the first place. Is having one policy to control all loading=auto behavior too coarse/powerful?

[eeeps]

Should this be revisited, in light of the Permissions-Policy → Document-Policy/Structured Headers changes?