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

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

From: Jatinder Mann <jmann@microsoft.com>
Date: Fri, 19 Apr 2013 17:26:50 +0000
To: "James Simonsen (simonjam@google.com)" <simonjam@google.com>, "Jake Archibald" <jakearchibald@google.com>
CC: "'public-web-perf@w3.org'" <public-web-perf@w3.org>
Message-ID: <0b9a18969cc74a70ad2630b469dfaa90@BLUPR03MB065.namprd03.prod.outlook.com>
On the topic of further delaying downloading a 'defer' resource based on its formatting or viewport position, I rather go with a MAY or SHOULD clause as well. As James said, this attribute really feels like a hint to the browser on the developer's intention, the browser may still make a better decision based on other relevant information. For example, most modern browsers paint regions greater than the viewport to ensure scrolling is smooth; the browser can decide whether or not it should further delay downloading a 'defer' resource based on its position beyond the viewport. Likewise, network requests typically happen before format has been computed, and based on opportunities, the browser may or may not want to wait for formatting to be computed to make that decision.

Have we decided on whether a 'defer' resource shouldn't delay the load event [1]? I can't think of a reason why this would be bad, but can definitely see the performance benefits of allowing scripts that trigger off the onload to run sooner. If there are no objections, I rather update the spec draft to support not delaying the load event for these resources.

Thanks,
Jatinder

[1] http://www.w3.org/TR/html5/syntax.html#delay-the-load-event

From: Jake Archibald [mailto:jakearchibald@google.com]
Sent: Friday, April 19, 2013 3:20 AM
To: James Simonsen
Cc: public-web-perf
Subject: Re: <img src="..." defer>

On Fri, Apr 19, 2013 at 5:22 AM, James Simonsen <simonjam@google.com<mailto:simonjam@google.com>> wrote:
Separately, I think MUST might be a little strong. Let me give you another example... Imagine the user quickly fling scrolls past hundreds of pages. Must we fetch every image along the way just because each was in the viewport for 1/60th of a second? I'd argue it'd be better to skip them.

Hmm, good point, MUST doesn't make sense here, as you said, MAY is better. Although that allows browsers to treat images as optional, and an implementation that doesn't download images at all would be compliant.

Why wouldn't we rely on an adaptive imagery-like technique all of the time though? It seems like if that works now, we should just continue to use it in future situations.

That will solve the Guardian & BBC case yeah, when that spec gets agreed upon and implementations land. If that spec also captures format negotiation, I'm out of use-cases for allowing JS to get at images before they're requested. Fair enough.
Received on Friday, 19 April 2013 17:29:39 UTC

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