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

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

From: Jake Archibald <jakearchibald@google.com>
Date: Thu, 18 Apr 2013 14:22:23 +0100
Message-ID: <CAPy=Jop5_=0W2pL8apSURa6JKe=QKazgJ3ptvXo4uu9Jhbz_PQ@mail.gmail.com>
To: James Simonsen <simonjam@google.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Thu, Apr 18, 2013 at 4:32 AM, James Simonsen <simonjam@google.com> wrote:

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

Browsers that don't have accurate into on viewport entry should trigger the
download sooner rather than fail to start downloading an image that should
be in-view. The spec makes provision for this. If the browser has genuinely
no idea on the scroll position of the viewport, it would opt to download
images as soon as they get layout (don't calculate to display:none).

Whether browsers are capable of knowing what's in their viewport,
developers are using hacky JS to try to create this behaviour and
conditional loading. This is a great opportunity to deliver this feature in
a network & device sensitive way.

Requiring an image to download _at the latest_ when it's in view is simply
common sense, otherwise we're saying images are entirely optional.


> Still need the display:none case for image polyfills through.
>>
>
> Can you elaborate on this case?
>

The BBC & Guardian look at the viewport and set the main article image src
to one more appropriate to the screen width. Unfortunately, the initial src
has already started download by this point so they end up downloading two
images. They could handle the image purely with js, but they want a non-js
fallback without doubling every image up with a <noscript>.

This particular issue will eventually be solved by adaptive imagery. But
other image pollyfills based on device capabilities will continue to have
the same issue.


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

I agree, that's why there's a huge gap in my proposal between when images
can download & when they must. Preventing images downloading when they're
hidden gives developers greater scripting control without compromising
pages for non-js users.

Jake.
Received on Thursday, 18 April 2013 13:22:50 UTC

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