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