W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2013

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

From: James Simonsen <simonjam@google.com>
Date: Wed, 17 Apr 2013 20:32:13 -0700
Message-ID: <CAPVJQimaNb25mBAD2te_uVM-c7jRM9aKUxTThcVGjHi4mTPujw@mail.gmail.com>
To: Jake Archibald <jakearchibald@google.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Wed, Apr 17, 2013 at 2:00 AM, Jake Archibald <jakearchibald@google.com>wrote:

> On Tue, Apr 16, 2013 at 8:16 PM, James Simonsen <simonjam@google.com>wrote:
>
>>  This is why I put a lot of wiggle-room here. For mobile connections &
>>> different thread scrolling. The viewport visibility bit is the very latest
>>> that images should be downloaded.
>>>
>>
>> My point on these is MUST and MUST NOT don't provide any wiggle room.
>>
>
> Is there a particular MUST or MUST NOT that you disagree with? The wiggle
> room is the browser can start downloading an image any time between it
> being in the DOM & not display:none, and in the viewport. The current spec
> is the browser MUST download the image as soon as the element is
> constructed, far less freedom.
>

For instance, saying, "MUST download once they are ... visible within the
viewport," means we have to do that the instant they become visible. I'm
saying that's not technically possible in any modern browser. It's better
just to say SHOULD.

"being in the DOM & not display:none" - this is to avoid downloading hidden
> imagery & allow JS to modify
> "in the viewport" - this is common sense really. Just speccing that images
> should be considered a non-optional part of the intended rendered output.
>

Yeah, that part I don't mind, but I think it's important that the browser
MAY download in that situation.


> This wouldn't cover the JS-polyfill case, and cases like a carousel of
>>> images where many of them are unlikely to load for most users.
>>>
>>
>> Why not? Why don't you want the browser to download the carousel images
>> if it's idle and bandwidth is cheap? It's strictly better to, in case the
>> user does click on the carousel.
>>
>
> I see your point on the carousel. In reality you would keep the images
> visible, but visually hidden by being in the non-visible parts of an
> overflow:hidden element. The browser would download these images with lower
> priority.
>
> So, would you rather the CSS asset loading stuff was opened out so the
> browser could download imagery/fonts that weren't on the page?
>

Yes, at least the browser should have the option. It seems like it'd play
nicely with something like image-set, where the browser could decide which
one is never used.


> Still need the display:none case for image polyfills through.
>

Can you elaborate on this case?

I want to restate my vision here. It matches up closely with Jatinder's
draft.

defer/delay/lazy is a hint that this resource is not needed for
above-the-fold rendering and not imperatively needed by the page. It's also
a hint that this resource _may_ be needed later (otherwise, why mention it
at all?). The browser should be free to decide the best time to fetch lazy
images.

I see these benefits:
- Page becomes visible sooner, because lazy, below-the-fold images don't
contend for bandwidth.
- Page becomes interactive quicker, because we don't have to wait for lazy
images before firing the load event.
- Saves bandwidth, because the browser can choose to never download a lazy,
below-the-fold image if the user never scrolls.
- Improves responsiveness, because the browser can proactively prefetch
invisible, lazy images if bandwidth is cheap.

I know it's crappy when the browser says, "I know what's best for you." But
in this case, I think it likely does. It knows a lot more about what's
going on with the system, the user's network, and how the user is
interacting with the page (scrolling, hovering over scrollbars, etc.). We
should leverage that information and defer/delay/lazy gives us the lever.

James
Received on Thursday, 18 April 2013 03:32:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC