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:10:01 +0100
Message-ID: <CAPy=Joo8NVzj_xWXie6ksC7=Y1WwyZseWc02cMCCv0NawVqD_w@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>, "James Simonsen (simonjam@google.com)" <simonjam@google.com>
On Wed, Apr 17, 2013 at 8:09 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Based on the discussion on the mailing list, performance workshop, and
> todayís conference call, I have put together a draft of the Resource
> Priorities spec as a framework for discussion:
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html.
> Seeing that the normative text is only a few paragraphs, we may want to
> eventually put this information in the HTML5 spec. As the Web Perf WG has
> been chartered to solve this performance problem, I want to make sure this
> working group agrees that the feature text solves the performance problem
> before we add this to the HTML5 spec.****
>
>
It doesn't go far enough for me. It doesn't allow JS to alter an img src
before the download is triggered, it doesn't take image positioning into
account. However, it's possible that this isn't the place for those
features.


> I donít agree that the user agent should look at style information or
> viewport placement to determine the download priority of a resource.
> Determining which resources are important for the page visuals is easiest
> for the developer, and the developer can decide on download priority of a
> resource by specifying or not specifying the attribute.
>

Unfortunately this is incorrect. The position of elements on a page is
judged by a CSS, which changes between devices and viewport dimensions.
Therefore, download priority (or if a download should happen at all) can't
be done with an attribute that doesn't take style & layout into account.
The bits of the spec that mention "the fold" are misleading in this regard.
Received on Thursday, 18 April 2013 13:10:32 UTC

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