W3C home > Mailing lists > Public > public-respimg@w3.org > March 2015

Re: Picture Element Explanation.

From: <steve@steveclaflin.com>
Date: Fri, 06 Mar 2015 09:59:18 -0600
To: Simon Pieters <simonp@opera.com>
Cc: Paul Deschamps <pdescham49@gmail.com>, Jason Grigsby <jason@cloudfour.com>, public-respimg@w3.org
Message-ID: <7dfb170dd0dcefcd5b86a967af82ff69@steveclaflin.com>
It amazes me how things circle around - this reminds me of the old 
Netscape lowsrc attribute, which I believe was an attempt to resolve the 
same basic issue.  Too bad that kicks off an additional request.

The whole preloading thing is a bit of a double-edged sword.  There are 
a number of pages that really hang some browsers for me (nhl.com in 
Chrome comes to mind), for which I believe the issue is way too many 
remote dynamically generated images (aka advertisements) all trying to 
load at once.


On 2015-03-06 04:28, Simon Pieters wrote:
> On Thu, 05 Mar 2015 16:30:23 +0100, Jason Grigsby <jason@cloudfour.com> 
>  wrote:
> 
>> In Bruce's article, he quotes Steve Souders as saying that the 
>> preloader  is
>> the "the single biggest performance improvement browsers have ever 
>> made".
>> 
>> In the link I provided, Andy Davies talks about how Google saw a 20% 
>> and
>> Firefox a 19% increase in average page speed after implementing the
>> preloader.
> 
> To be fair, I think those numbers are not entirely relevant for
> speculatively loading images per se. The biggest performance
> improvement  is from speculatively loading other scripts and
> stylesheets while the HTML  parser is blocked on loading a script. I'm
> not aware of comparisons of not  speculatively loading only images.
> 
> But even if you don't load images speculatively, the browser could
> still  start loading images when the real parser sees the <img> which
> can happen  before CSS has loaded, as in my example in
> https://lists.w3.org/Archives/Public/public-respimg/2015Mar/0043.html
> (there are no scripts in the example and thus nothing is loaded
> speculatively).
> 
> If you were to defer image loading until layout is known, it needs to
> be  deferred in both the speculative parser *and* when the real parser
> creates  the element. Browsers have never waited with loading images
> until layout  is known. As can be seen in my example, the best-case
> scenario would be  that images pop in 1 RTT after first paint if
> loading images were to wait  for layout.
> 
> Put another way, the perf regression of the proposal would probably
> not be  20% page loading time, but instead having first paint be
> without any  images and have images come in 1RTT later.
Received on Friday, 6 March 2015 15:48:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:16 UTC