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