W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2015

Re: [whatwg] <iframe async>

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Fri, 27 Feb 2015 09:58:50 -0500
Message-ID: <54F0862A.6010601@mit.edu>
To: David Bruant <bruant.d@gmail.com>, whatwg@lists.whatwg.org
On 2/27/15 9:54 AM, David Bruant wrote:
> I jumped a bit to conclusions quickly, but I think the point remains. If
> the iframe is loaded in parallel (different thread, different process,
> anything that isn't blocking the parent), then its loading doesn't block
> the parent loading.

Sure it does, to the extent that there is congestion on the TCP level, 
contention over processor timeslices, etc.

I mean, it's not blocking in the sense that the parent can't finish 
until the iframe does, but it _can_ slow down the parent in various ways.

> I don't understand the concern with the shared net connection.
> Does the spec mandates the order of resource loading between parent and
> iframe?

No, it does not.  UAs use various heuristics for it right now.  What's 
being proposed, afaict, is a way of providing a hint to those heuristics 
to deprioritize the iframe in question.

> If not, then browsers have enough liberty today to prioritize parent's
> resource loading over iframe without the need of an opt-in from devs,
> maybe?

They have the liberty, but they don't always have enough information to 
know when to prioritize what.

>> Please define "async loading" in the context of your question?
> What I meant was "loading that doesn't block parent's loading".

Loading iframes never "blocks" the parent's loading in the sense that 
you seem to be thinking of it.

-Boris
Received on Friday, 27 February 2015 14:59:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:27 UTC