- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 27 Feb 2015 09:58:50 -0500
- 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