Bugzilla

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`.

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`.