Open Bug 1634480 Opened 5 years ago Updated 4 years ago

The HTML parser does not always kick off speculative loads before inserting the first element

Categories

(Core :: DOM: HTML Parser, enhancement)

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.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.