Re: [whatwg] <iframe async>

Le 27/02/2015 17:27, David Håsäther a écrit :
> On Fri, Feb 27, 2015 at 4:37 PM, David Bruant <bruant.d@gmail.com> wrote:
>> You said that you got feedback from someone asking for this.
>> What is the behavior they currently implement?
> Since I'm one of the people Anne talked to, I can expand a bit on what he said.
>
> Right now, we insert iframes containing ads on DOMContentLoaded (but
> this is not significant).
Perhaps it is. As someone else said on the thread, this delays the load 
event.

> We want these to have normal priority
> (otherwise we could insert them on load), but we don't want want them
> to delay load, mainly because *our* site is perceived as slow when the
> progress bar is shown.
Which progress bar are you referring to? The browser load UI indicator?

> I don't think it's too uncommon for people to
> wait for the progress bar to disappear before they start interacting
> with the page. I do that sometimes, e.g. to make sure I don't misclick
> because an image loads and the page jumps.
The "progress bar" problem and the load event problems seem distinct 
(but they're not because of how browsers implement the load UI indicator).

> The bfcache problem is another thing that would be really nice to solve, yes.
 From the problem statement, maybe the attribute that should be added is 
"does-not-delay-load" (which could be used on images or any element 
which loads something that delays the load event).

IIRC some time ago, there was discussion on how an web page could tell 
the browser it's loaded (so the browser can take a screenshot for 
thumbnalil purposes). Usually, the load event is used, but it's 
unreliable (for JS-dependent SPA for instance), so it's be interesting 
if the webpage could tell "I'm ready". Does someone know where we're at 
on this topic?
It seems like it would solve the problem at hand.

David

Received on Friday, 27 February 2015 16:51:46 UTC