- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 06 Mar 2015 11:28:02 +0100
- To: "Paul Deschamps" <pdescham49@gmail.com>, "Jason Grigsby" <jason@cloudfour.com>
- Cc: "public-respimg@w3.org" <public-respimg@w3.org>
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. -- Simon Pieters Opera Software
Received on Friday, 6 March 2015 10:28:34 UTC