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

On Mon, Apr 15, 2013 at 2:32 AM, Jake Archibald <jakearchibald@google.com>wrote:

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

Just to be clear, this isn't a problem today, because people use JS based
solutions to avoid this, right? IIUC, you're saying we should enable a
markup based solution (and I'd support that), right? Or is it actually
common that there are display:none images in practice (that would thus be
getting downloaded in today's world)?

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

Great, thanks for clarifying.


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

I fully support trying to get rid of nasty javascript hacks here.


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

We can *speculatively* do so. But blocking script can obviously always
change the images' styles.


> '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.
>

I appreciate the desire for simplicity. I am concerned there are too many
use cases here though to adequately solve with a single mechanism. I still
haven't thought it through completely, but my gut instinct is to split it
out into:
* "defer" as a mechanism to indicate lower priority for better browser
resource prioritization.
* i suck at naming, but "waitforstylebeforedownloading" for fuller control.
This makes it clear it's thwarting preloading and has a stronger semantic
declaration of desire for lazy loading. This would work as you currently
propose.

And I don't believe there's a complete solution for the primary image with
new image format (with limited support) except content negotiation, which I
understand is still very controversial.

Cheers.