The HTML parser does not always kick off speculative loads before inserting the first element
Categories
(Core :: DOM: HTML Parser, enhancement)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
(Blocks 1 open bug)
Details
I observed this in these profiles of mozilla.org loading during app link startup. In the "bad" profile, many network requests kick off after a delay.
Good profile: https://bit.ly/2KM65Op
Bad profile: https://bit.ly/3bSmb54
GeckoView does some expensive work during the initial-document-element-inserted
notification. This work takes 150ms on a Moto G5. This work often runs before speculative loads are kicked off, as evidenced in the "bad" profile. We should be able to initiate the speculative loads 150ms earlier just by changing the order here.
In the "good" profile, where the speculative loads are kicked off before the first element is inserted, nsHtml5SpeculativeLoad::Perform
is called directly from nsHtml5TreeOpExecutor::RunFlushLoop
.
In the "bad" profile, where the speculative loads are delayed until after the first opAppendToDocument operation has been performed, nsHtml5SpeculativeLoad::Perform
is called via a nsHtml5LoadFlusher
runnable in the main thread event loop, and not from nsHtml5TreeOpExecutor::RunFlushLoop
.
Updated•5 years ago
|
Description
•