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

On Mon, Apr 15, 2013 at 3:34 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> # 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?
>

By "cheap" I mean cheap to make the connection to the server,
not necessarily cheap to complete the image download. Eg, making a
connection is much cheaper on wifi than 3g.

The wins are:
* Avoid unnecessary image downloads (hidden images)
* Allow the browser to delay/avoid out-of-viewport imagery, depending on
network, meaning more important resources get priority
* Allow JS to alter src before download, while allowing a non-js fallback

I'm much less interested in server/CDN costs that come at the expense of
user experience. Some of the above will reduce costs, but that's not the
goal.

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?
>

I want to rid the world of nasty javascript hacks for lazyloading and
changing src, while giving the browser the freedom to
avoid unnecessary image downloads. Visibility and position depend on layout.


>
>
>> ** 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)...
>

This is my worry about the feature, and needs thought through by people
clever than me.

I don't see an issue with "Begin preloading resources if the network is
idle." in terms of blocking scripts. If CSS has downloaded we can still
parse ahead and calculate layout to determine if an image should download.

'Earlier notification of “first paint.”' - more concerned about this.
Images with 'the new attribute' will be blocked on CSS download. I wouldn't
use the new attribute on primary images (say, the main image of an article)
so there's not a problem there, unless, as you point out, I wanted to do
some javascript magic on it.

Yeah, this needs attention of people with more network smarts than me.


> 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?
>

I'm open to it being two separate things. Having one attribute makes it
simple, whereas a separate prioritisation attribute could be used across
script, css, audio, video, imagery etc etc.