W3C home > Mailing lists > Public > public-respimg@w3.org > February 2013

Re: CfC: to publish "The srcset attribute" specification as a First Public Working Draft (FPWD)

From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 5 Feb 2013 23:53:32 +0100
Message-ID: <CACj=BEhHP8aR46GcLnT2eO4xU_45AYaAzMpWj1unD3WF=jmvZA@mail.gmail.com>
To: Mat Marquis <mat@matmarquis.com>
Cc: "Nathanael D. Jones" <nathanael.jones@gmail.com>, "public-respimg@w3.org" <public-respimg@w3.org>
Nathanael,

I'd like to add that you are highly underestimating the amount of delay
postponing fetching of images until after the page has layout will
introduce.

The average delay of a 4G network is around 150 ms. For a 3G network it is
around 400 ms [1]

That means that in the best case scenario of a page with a single small CSS
(that fits into the initial congestion window), and no External JavaScript
in the head, we are looking at at least 400 ms delay in the page's overall
page load for 3G users. That is a lot!

Let's look at a real life loading scenario of a Web page containing several
CSS files from different hosts (external font library is a common case), as
well as a few external JavaScript files from various hosts (CDN based
JQuery & local scripts)

In this case you are looking at at least 2-3 delays more (establishing
connections, requesting & fetching resources, which at least some are
bigger than the 15KB of the initial congestion window), even with SPDY.
Add to that CSS & JS parsing & rendering/execution, creation of DOM,
RenderTree and Layout (none of which is negligable on mobile devices), and
you have added 2-3 seconds to an average page.

I'm afraid that the performance regression that will result from
waiting for layout before requesting images is just too much for it to be
a viable option.

Yoav

[1]
http://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/


On Tue, Feb 5, 2013 at 11:27 PM, Mat Marquis <mat@matmarquis.com> wrote:

>
> On Feb 5, at 3:36 PM, Nathanael D. Jones wrote:
>
> I think many people were expecting a solution based on element size.
>
>
> I would be interested in seeing data to support this assertion.
>
> While that may not be a use-case you've aimed to solve, *I think it
> should be the *primary* use-case*, as it provides a *simple solution to
> nearly every other use-case documented*.
>
> *Here's my full proposal:*
>
> https://gist.github.com/nathanaeljones/4706093
>
>
>
> Where your goal is to selectively load images based on the size of the
> containing element and youíre comfortable delaying the requests for those
> assets until after the layout has been painted, the functionality youíre
> looking for could be easily accomplished using JavaScript and data
> attributes.
>
> In terms of the above as a native solution: your proposal involves heavily
> modifying the syntax of media queries (with syntactical overlap between
> your proposal and the existing method of specifying media types),
> repurposing `width` and `height` attributes, and delaying image requests to
> well beyond the initial parsing of the markup (waiting until CSS and JS is
> requested, transferred, and rendered to begin requesting image sources). As
> a first step, I might recommend reaching out to browser representatives to
> determine the implementation viability of your proposalóthere are several
> members of the RICG that would likely be willing to offer you feedback.
>
> I understand that this is a subject to which a great deal of people have
> given thought. Iím happy to continue this discussion on the RICG mailing
> list, but Iím sure you can understand where we wonít be withdrawing the
> `picture` proposal based on proposals that havenít yet been thoroughly
> vetted or discussed at any length. The HTML WG Administrative list doesnít
> seem like the appropriate venue for those discussions.
>
> Thanks,
> Mat Marquis
>
>
> For the record:
>
> I do not believe the advantages of slightly-earlier prefetching outweigh
> the benefits of a CSS-based approach. There are many possible optimizations
> available to ensure the delay can be reduced to ~40ms for a cache miss
> (Probably ~15ms with SPDY), and it is simply not worth the markup
> complexity required.
>
> Best regards,
> Nathanael Jones
>
>
> [ snip ]
>>
>>
>>
>
>
Received on Tuesday, 5 February 2013 22:54:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:39 UTC