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.

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