1458079 - Nimbledroid's wikia.com page load test is 2x slower in GeckoView than WebView

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect, P2)

Description

[Chris Peterson [:cpeterson]]

Nimbledroid test results for http://www.wikia.com/fandom

Klar+WebView = 3.7 seconds

Klar+GeckoView = 7.7 seconds

Klar+WebView test results on Nimbledroid:
https://nimbledroid.com/my_apps/org.mozilla.focus.debug?a=d78f816d-3591-4203-9820-bed76f107406

GeckoView and WebView test results spreadsheet:
https://docs.google.com/spreadsheets/d/1vE0b3tawWY9vVNq9Ds6CiA9XZ6LStkcXZl3F8dwXid8/

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey cpeterson, does this impact Desktop? If not, I don't think this is something the Quantum Flow team is currently triaging.

Comment 2

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

P2 feels right as a default for performance bugs tied to our nimbledroid informed perf work.

Comment 3

[Chris Peterson [:cpeterson]]

Here is a profile of Firefox Nightly 62 on Windows 10 loading wikia.com. The page load takes about 1 second in Chrome and almost 3 seconds in Firefox.

https://perfht.ml/2LnZBo5

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

dholbert, there is some slow reflow here. Could you take a look at that part of the profile? Something grid related?

Comment 5

[Kannan Vijayan [:djvj]]

Ted, can you take a look at the JS execution in this profile?  The problem just seems to be slow JS execution for at least half of the profile here.  Nothing specific seems to stand out.  This might be a good target to include for later-in-the-year JS performance optimization goals.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Olli Pettay [:smaug] from comment #4)
> dholbert, there is some slow reflow here. Could you take a look at that part
> of the profile? Something grid related?

Yeah - in particular, there's a single initial reflow that takes 106ms: https://perfht.ml/2kwk2mi
(That time -- 106ms -- is what's reported in the tooltip when I hover the blue "reflow" bar.  The "Running Time" samples only total up to 49ms, but I'm assuming that some of those are missing, or they're recorded with the wrong duration or something, since I know that happens on some platforms.  I'm assuming I should trust the measurement on the blue "Reflow" bar more than the sample times.)

The reflow includes nested block -> grid -> flex -> flex containers.  It's hard to know where precisely the issue is coming from, but I'm guessing we're probably re-measuring the same content several times when technically we don't need to.  It's possible bug 1377253's flex-item-size-caching will help with this, and/or we might need to cache size measurements for grid items more aggressively as well.

Anyway -- since there are possible several slow areas here, I'll spin off the layout improvements to a separate bug which I'll mark as blocking this bug.

Comment 7

[Daniel Holbert [:dholbert]]

(I spun off bug 1465205 for the layout bits noted in comment 6.)

Comment 8

[:Harald Kirschner :digitarald]

:djvj wanted to add Ted, done now.

Comment 9

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

Looking at http://marvel.wikia.com/wiki/Black_Panther (https://perfht.ml/2ONhGgZ) -- typically 3s webview vs ~8s geckoview -- there are several interesting things:

1) the top banner appears before loading stops on GV, and after loading stops on WV.  This says that either the site is kicking it off "later", or WV is deciding that process is finished off a different signal, or something along these lines.

2) The profile shows a 1.3s CreatePatternForFace() call which is all FontConfig calls (on Linux).

A bunch of time spent in the jit early on, but that may be ok.

Comment 10

[Daniel Holbert [:dholbert]]

Following up on comment 4 / comment 6 - I suspect the long (106ms) initial reflow here is not a key differentiator between GeckoView & WebView here. I posted some measurements in bug 1465205 comment 2 which indicate that we're actually a good deal faster than Chrome on the initial layout here, at least on desktop. (And 106ms is actually entirely within the range of Chrome-for-desktop first-layout duration for this site.)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Chris, could you retest. Lots of changes since this bug was filed, for example bug 1270059.

Comment 12

[Chris Peterson [:cpeterson]]

(In reply to Olli Pettay [:smaug] from comment #11)

Chris, could you retest. Lots of changes since this bug was filed, for example bug 1270059.

The Nimbledroid test results for wikia.com say that GeckoView is now 5x slower than Chrome 72 Beta. I don't trust these Nimbledroid tests and the test results have not be updated since February. I will ask if there is newer data.

https://health.graphics/android/graph?site=http://marvel.wikia.com/wiki/Black_Panther

Comment 13

[Chris Peterson [:cpeterson]]

I'm going to close this bug as WFM.

Manual comparison of the time to load the full page (ignoring the progress bar and just watching the images at the bottom of the page are loaded) on my Moto G5 for the "VISIT FULL SITE" page linked from the bottom of the mobile page http://marvel.wikia.com/wiki/Black_Panther:

Fennec 68 Nightly: about 6 seconds
Fenix (GV 67 Beta): about 3 seconds
Chrome 73: about 2 seconds