Re: <img src="..." defer>

Thanks for putting together this proposal. I am still digesting it, but I
had some questions in the meanwhile.

On Sun, Apr 14, 2013 at 10:52 AM, Jake Archibald
<jakearchibald@google.com>wrote:

> Hi,
>
> I know this group is looking at resource priorities, but I'm interested in
> taking it a big further for images, and perhaps other visual media such as
> video.
>
> # Problems I'd like to solve:
>
> Developers are using hacks or ending up with unnecessary downloads when
> they use JavaScript to change the src of an image, but want to provide a
> non-JS fallback (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842).
> Although this particular case will be solved with something like srcset,
> there are other cases like conditionally using an image format with limited
> support.
>

> Developers are using hacks to lazy-load images that are likely to be
> outside the viewport initially. These hacks use heavy scroll listeners and
> don't take the connection type into account.
>

> Images within elements that are never shown are downloaded.
>
> # "defer" behaviour:
>
> Images with 'defer' MUST NOT download while they aren't in a document, or
> their calculated 'display' style property is 'none'.
>

> The download state of images with 'defer' MUST NOT delay the 'load' event
> of the window.
>
> Images with 'defer' MAY download once they are in the document, and their
> calculated 'display' style property is not 'none'.
>
> Images with 'defer' MUST download once they are in the document, and their
> calculated 'display' style property is not 'none', and any part of the
> image would be visible within the viewport. If visibility within the
> viewport is uncertain (due to element size determined by image dimensions),
> the image MUST download.
>
> There's been a lot of discussion on
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842, I'll try and sum up
> the pros & cons but will ping Ilya to add anything I may have missed.
>
> # Pros
> * Imagery in hidden elements that may never be seen by the user aren't
> downloaded
> * JS can modify the src of images before their original src downloads, by
> initially hiding the image with CSS
> * The browser gets more freedom in regards to image downloading, allowing
> it to do the best thing given the user's connection type & interaction. Eg:
> ** If making a connection is cheap & quick (eg, fast wifi), the browser
> may delay downloading imagery until it's in the viewport, which can avoid
> unnecessary downloads way below the fold
>

What's the win here? Is it avoiding contention with above the fold images
for better page load experience? Or saving client downloads (you said it's
cheap in this case...so why bother?)? Or saving server-side / CDN costs?

As far as avoiding contention with above the fold images, I would think it
would be better just to demote priority and let the UA schedule
"appropriately", rather than outright block/delay the download (not to
mention blocking the image download on style resolution). If this is the
primary motivation, can you clarify why it's necessary/good to block the
download on style resolution?


> ** If making a connection is expensive & slow (eg, 3g), the browser may
> download all imagery that isn't calculated display:none to avoid waking the
> radio up later and using up battery
>

> # Cons
> * When creating images with js, you'd need to set .defer to true before
> setting .src, else the image would download straight away
>
> I don't see this as a big problem, devs know the ordering matters, you
> already have to set src after load events
>
> * Deferred images cannot be downloaded early by preloaders unless they
> calculate page styles & images that are at the top of the page may download
> later as they need to wait for style calculation to know if they should
> download or not
>
> Not a big deal. Images are low priority downloads anyway compared to JS &
> CSS so waiting for layout isn't a problem. Also, primary imagery shouldn't
> use this attribute.
>

Can you explain why you think waiting for layout isn't a problem in the
context of:
1) SPDY & HTTP/2.0, which would let browsers request low priority resources
sooner without introducing contention
2) Chrome 27 resource scheduling changes where images are sometime
requested before stylesheets have completed downloading? See
https://docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=en&forcehl=1
and
note the "Analysis of Major Changes" section which identifies "Aggressively
preloading when network is idle." (preloads images when network is idle).
This is identified as a big win.

Perhaps the main reason it's not an issue is because above the fold imagery
shouldn't use this attribute? But then, that would mean that above the fold
imagery can't conditionally use image formats with limited support (one of
the earlier targeted problems to solve)...


>
> * Firing the load event before all images download may skew metrics
>
> By putting 'defer' on an image you're saying it isn't required to consider
> the page loaded. I don't think this is an issue.
>
> * Lazy-loading isn't good on mobile connections
>
> The browser isn't required to lazy-load. It can make the choice based on
> the connection, which is far better than the hacky JavaScript developers
> are using to currently perform lazy-loading.
>

+1


>
> * Developer can't indicate they'd rather have aggressive lazy-loading, to
> save CDN costs
>

Listing this as a con seems to answer part of my earlier question about the
pro for cheap,fast connections. Although I'm unclear on the wins.


>
> Feature, not a bug. Would rather the browser did what's best for the
> connection type. The developer could always display:none the images, and
> use a scroll listener to show them as they come into view, but I wouldn't
> want to make that any easier.
>

+1


>
> Cheers,
> Jake.
>

Skimming (sorry, didn't read fully, it's rather long) that linked bug
thread, it seems like there's some discussion on whether or not this should
be split out into two separate attributes (one for simple prioritization
and one for fuller control, blocked on style resolution). Can you (or
someone) summarize the pros/cons there?