Re: [whatwg] <iframe async>

This is obviously larger than the particular set of use cases mentioned
here, but another set of iframe discussions I've seen lately have centered
around going off thread or out of process. I wonder if there is a more
basic primitive here that can apply to all these use cases [and perhaps
even allow for new behaviors we haven't thought of]? Perhaps a new email
thread would be appropriate for such a discussion?

In all these use cases we want to defer content within an iframe or render
content off the main thread. Perhaps there is a fundamental API whereby we
can decouple content from container (for non-seamless iframes)? Perhaps
lifetime management, and the question of what context the content is
loaded, and rendered in can be decoupled from the lifetime and layout of
the container iframe?

We've toyed with this idea internally in the Chrome <webview> tag
<https://developer.chrome.com/apps/tags/webview> , but I am less
experienced with the intricacies of iframes, so I don't want suggest any
specifics for an API for iframes, but rather simply discuss the
implications of decoupling content from container. If there is interest in
that conversation, I can move that to a new email thread. Thanks,

Fady Samuel
Chrome Apps <webview> Tech Lead

On Fri, Feb 27, 2015 at 1:31 PM, Ashley Gullen <ashley@scirra.com> wrote:

> Perhaps "independent" is a better name than "async", indicating the iframe
> content is independent of the main page. Browser loading UI, load events,
> "fast back" and possibly performance tools would not take in to account
> independent iframes, since they are explicitly marked as not important to
> the working of the main page.
>
> I think there are widespread use cases for this: ads and those social icons
> (facebook, tweet etc) are all iframed, and I've seen pages look like
> they're really slow because they're waiting for a Tweet button to load when
> the main page was ready long ago. Performance tools is another case I bring
> up because I've seen some tools say the page took say 2 seconds to load,
> when the main page was really ready after 300ms and then it spent 1.7
> seconds waiting for the Tweet button to finish its thing. It would be nice
> if performance tools could identify the independent iframe and not include
> it in such calculations.
>
> Ashley
>
>
> On 27 February 2015 at 17:28, David Håsäther <hasather@gmail.com> wrote:
>
> > On Fri, Feb 27, 2015 at 5:51 PM, David Bruant <bruant.d@gmail.com>
> wrote:
> >
> > >> 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?
> >
> > Yes.
> >
> > >> 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).
> >
> > I'm mainly talking about the load indicator for my use case, I'm not
> > listening to the load event.
> >
> > >> 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).
> >
> > Yes, good point, there are probably use cases outside of iframes, e.g.
> > third-party images (like avatars, that could be considered
> > unimportant).
> >
> > --
> > David Håsäther
> >
>

Received on Friday, 27 February 2015 18:52:51 UTC