Should lazy loading be bound to scripting being enabled?

[SebastianZ]

The spec. around lazy loading steps current reads like this:

The will lazy load image steps, given an img element img, are as follows:

1. If scripting is disabled for img, return false.

Note: This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when.

I get the point about having a way to disable this feature in order to avoid tracking. I am wondering, though, whether lazy loading of images should really be bound to scripting being enabled or not. What if a user agent does not support scripting? What if a user has scripting disabled for other reasons than as anti-tracking measure, e.g. to save bandwidth? What if a user generally doesn't want to be tracked but may still want to accept lazy loading to save bandwidth (accepting to be potentially tracked through this matter)?

Therefore I think the option to disable lazy loading should be made independent of whether scripting is enabled or not. User agents should still be requested to provide an option to disable it, though the implementation should be up to them.

Sebastian

[miclf]

I second this interrogation. Seeing that lazy-loading of images didn’t work when JavaScript was disabled in the user agent, I’ve bugged people on Mozilla’s Bugzilla yesterday, saying that

As an author, I’ve been surprised by [the reliance on scripting being enabled]. Seeing no relationship between the unavailability of JavaScript and the loading of HTML images by the browser, I would expect loading="lazy" to be honoured regardless of the ability to run JavaScript in the page, so that users could still benefit from the performance improvements coming from the attribute.

Someone then swiftly told this was intentional, and pointed me to the relevant part of the HTML spec.

I fully understand (and agree with) the choice of favouring privacy over performance. However, I’m also wondering if we could give the user the ability to decide, via the user agent, as @SebastianZ proposes. Lazy-loading could help to save tremendous amounts of requests on image-heavy websites, so maybe we could benefit from a more nuanced solution than the current implementation, which would allow lazy-loading to still be honoured even though scripting would be disabled or unavailable.

(By the way, thanks for updating the docs on MDN, Sebastian!)

[zcorpan]

cc @domfarolino @addyosmani @smfr @emilio

[domfarolino]

I pretty much defer to @smfr & @othermaciej, as I vaguely remember (plz don't quote me) it was Apple that originally brought up this restriction. Regarding a "configurable" alternative, which were you thinking:

• Adding something to the API (if so, I think I'm against that), or...
• Allowing implementations to basically choose what to do with scripting enabled/disabled, and not specify its relationship to lazy loading

[annevk]

(I vaguely recall being involved in advocating for this, but not a 100% sure.) I'm not sure making it configurable is good when sites disable scripting as they might have specific expectations when doing so. Making it configurable when users disable scripting seems okayish, but that's pretty niche to begin with.

[domfarolino]

(I vaguely recall being involved in advocating for this, but not a 100% sure.

Ah yep I think so, sorry for forgetting. I pretty much agree with @annevk's comment FWIW

[zcorpan]

So, should we change the to "optionally return false"? That would allow either behavior when scripting is disabled, and UAs can allow users to toggle these individually.

[annevk]

Would that lead to undefined behavior in the sandboxing case?

[zcorpan]

Yes, good point. That's not great.

If we consider only the sandbox case, should lazy-loading work there? It doesn't seem like quite the same situation as the user having disabled scripting to avoid tracking.

[annevk]

Our thinking was that it should not, see also #5495 (comment).

[SebastianZ]

Excuse the very late reply! I totally missed the conversation about this.

@domfarolino wrote:

Regarding a "configurable" alternative, which were you thinking:

• Adding something to the API (if so, I think I'm against that), or...
• Allowing implementations to basically choose what to do with scripting enabled/disabled, and not specify its relationship to lazy loading

The latter. The note about the relationship between scripting enabled/disabled and lazy loading should be replaced by a general hint that user agents should implement some way to let the user control whether lazy loading is enabled/disabled for the reasons mentioned earlier. How they do it can be let up to them but the spec. might still provide hints for possible options, i.e. binding it to scripting vs. an individual option or the integration into a general tracking protection concept.

Sebastian