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

The use cases here sound great to solve.

The main concern I have is a bikeshedding one. The 'defer' behavior
described here is quite different from how <script defer> works (it
makes the load happen unconditionally as soon as the main HTML has
downloaded, no sooner and no later).

So I wonder if we should use a different attribute name.

/ Jonas

On Sun, Apr 14, 2013 at 7:52 PM, 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
> ** 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.
>
> * 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.
>
> * Developer can't indicate they'd rather have aggressive lazy-loading, to
> save CDN costs
>
> 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.
>
> Cheers,
> Jake.

Received on Sunday, 14 April 2013 18:39:11 UTC