Skip to content
This repository has been archived by the owner on Sep 12, 2018. It is now read-only.

Lazy loading of images #1

Open
nhoizey opened this issue Feb 24, 2016 · 8 comments
Open

Lazy loading of images #1

nhoizey opened this issue Feb 24, 2016 · 8 comments

Comments

@nhoizey
Copy link

nhoizey commented Feb 24, 2016

I see in this draft a section about lazy loading of images, which is really nice!

I know —thank you @hteumeuleu for this tweet— that IE11 and Edge already support a lazyload attribute, but they are alone and the draft spec has been abandonned, inviting us to look at resource hints… which don't seem to contain anything on this topic.

So, thanks a lot for this, I hope it will come soon to every browser!

Ok, that's not really an issue… ;-)

@nhoizey nhoizey changed the title Lazyloading of images Lazy loading of images Feb 24, 2016
@yoavweiss
Copy link
Collaborator

The image lazy loading section is still very "handwavy" - we need to flesh out the use cases and see how they can be tackled with a mix of directives, default browser behavior and JS based overrides and APIs.

But I'm glad there's demand :)

@Krinkle
Copy link

Krinkle commented Feb 25, 2016

It seems we're forced to hand ourselves contradictory design requirements:

  1. Current browsers that don't implement the spec (yet), if JavaScript fails/unsupported/disabled, the image should display.
  2. Current browsers without this new feature should benefit lazy-loading through a JS-powered fallback.
  3. Future browsers with this feature listen to whatever syntax we settle on can natively ensure all goes well.

Point 3 is easy.
Point 1 requires we keep <img src> as-is with something added to it.
Point 2 requires we don't keep <img src> because otherwise the image would load regardless and make lazy-load futile.

One way would be to accept that lazy-loading will only apply to new browsers and one would have to resist temptation to make it work for current/older browsers.

Another way would be to accept we need to vary the HTML itself, perhaps based on an indicator in the request headers (other than User-Agent, of course).

@igrigorik
Copy link
Member

I know —thank you @hteumeuleu for this tweet— that IE11 and Edge already support a lazyload attribute, but they are alone and the draft spec has been abandonned, inviting us to look at resource hints… which don't seem to contain anything on this topic.

That hint has nothing to do with actual lazyloading. All it does in old IE is downgrade priority of the fetch.

@nhoizey
Copy link
Author

nhoizey commented Feb 29, 2016

downgrade priority of the fetch

This is a form of lazy loading IMHO, even if I know most people define lazy loading by loading when (soon to be) in the viewport.

@Krinkle
Copy link

Krinkle commented Feb 29, 2016

Fair enough. Though imho that's more commonly known as "deferred loading". (Commonly implemented by starting the load of all images from a window.onload callback).

In deferred loading, one will observe that all images load eventually (albeit deprioritised).

In lazy loading, a measurable outcome is that some images will never load (given the user's interaction with the viewport) and thus save absolute bandwidth.

Although deferred loading might still save bandwidth depending on how long a user leaves a page open.

@nhoizey
Copy link
Author

nhoizey commented Feb 29, 2016

@Krinkle @igrigorik ok I agree, there are 2 needs:

  • defer loading to prioritize the most important parts and display ATF content ASAP,
  • "lazy" load only what's really needed for rendering of currently (maybe a little extended) visible viewport, to save bandwidth, reduce data plans usage.

I think CPP should let us manage both separately, even if they overlap a little.

@igrigorik
Copy link
Member

I think CPP should let us manage both separately, even if they overlap a little.

See https://discourse.wicg.io/t/a-standard-way-to-lazy-load-images/1153/12.

@nhoizey
Copy link
Author

nhoizey commented Feb 29, 2016

@igrigorik thanks for the link, this discourse thread is great!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants