Re: [whatwg] <iframe async>

Le 27/02/2015 15:58, Boris Zbarsky a écrit :
> 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.
Sure.
The TCP situation is probably about the same if parent and iframe are in 
same thread.
But for processor timeslices, the amount of blocking seems insignificant 
compared to the current situation as long as you have the hardware to 
run 2 threads in parallel, no?

>
>> 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.
To achieve this priorization, currently, authors would use a bit of JS 
to delay adding the iframe to the document. It seems like it solves all 
the issues listed in the original message (load UI, load event, "fast 
back").
What is the significant benefit to adding an HTML attribute to solve 
this problem?

David

Received on Friday, 27 February 2015 15:16:04 UTC