1609682 - preload required content and parent process scripts at startup of GeckoView

Status: NEW

(GeckoView :: General, defect, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

When Content (and master) processes start, there are a number of scripts that will be needed virtually always once we're load to load a URL or fixed content. If we can start their import/parsing/etc earlier, we'll be able to actually load a URL sooner (hopefully less delay from keyboard input or Intent/etc until we actually start the load). There's probably at leat 70ms, perhaps as high as 100ms, that could be saved here in some cases.

See for example https://perfht.ml/375JTIM , particularly the chromeUtils.imports

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

If we fix enough instances of 100 ms it can add up... Mike is P3 still correct here?

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

This would likely be owned by the platform folks: Eric, Andrew – can you prioritize this?

I will note that this case may not be covered by our current automation: it would fall under cold startup app link with browsertime but that test is currently running without browsertime.

Comment 3

[Andrew Creskey [:acreskey]]

Michael, you are correct that this case is generally not handled by browsertime automation since the browser conditioning would hide this delay.
But it would be something that users experience and that we'll one day capture in tests.

Comment 4

[esmyth]

I think the qf priority tag is appropriate and I'm very interested in the feasibility of this making the 75 train. 70-100ms is a lot for a startup to a page load.

I have an open thread in Riot with mleclair to determine if the FNPRMS al test will detect this case.

Comment 5

[Emily Toop (:fluffyemily)]

This is related to some of the perf work that :bdahl has already addressed in bug 1611820. We shall see if we can get this addressed in GV75.

Comment 6

[Brendan Dahl [:bdahl]]

I'm going to lower the priority of this one as it's a less common use case. Usually when fenix starts, a URL is immediately loaded without the users interaction because of app-link or there is a URL already loaded in the browser. In those cases eagerly loading the components does nothing to speed things up.

The results of some investigation I did with eagerly loading all the slow loading cu.imports in 'app-startup':
Benchmark 1:

• Load gv example
• Open new tab
• Enter url
• Time from url entered to DOMContentLoaded

Benchmark 2 (more common use case):

• Kill gv example
• Trigger app link
• Time from XRE_main to DOMContentLoaded

I ran all the above 15 times on a moto G5. Benchmark 1 showed 80-90ms improvement. Benchmark 2 showed no changes.

The bad thing about eagerly loading is we will need to play whack-a-mole and keep adding slows scripts to preload. I'm inclined to say we should focus the cold startup/app-link case (bug 16200790) and work overall on minimizing the imports time.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

That would be bug 1620079

Comment 8

[Bas Schouten (:bas.schouten)]

(In reply to Brendan Dahl [:bdahl] from comment #6)

I'm going to lower the priority of this one as it's a less common use case. Usually when fenix starts, a URL is immediately loaded without the users interaction because of app-link or there is a URL already loaded in the browser. In those cases eagerly loading the components does nothing to speed things up.

The results of some investigation I did with eagerly loading all the slow loading cu.imports in 'app-startup':
Benchmark 1:

• Load gv example
• Open new tab
• Enter url
• Time from url entered to DOMContentLoaded

Benchmark 2 (more common use case):

• Kill gv example
• Trigger app link
• Time from XRE_main to DOMContentLoaded

I ran all the above 15 times on a moto G5. Benchmark 1 showed 80-90ms improvement. Benchmark 2 showed no changes.

The bad thing about eagerly loading is we will need to play whack-a-mole and keep adding slows scripts to preload. I'm inclined to say we should focus the cold startup/app-link case (bug 16200790) and work overall on minimizing the imports time.

Lowering qf priority based on this comment.