1454477 - [meta] Investigate progress bar behavior difference between GeckoView and WebView

Status: NEW

(GeckoView :: General, enhancement, P3)

Description

[No-Jun Park [:njpark]]

Currently, both the telemetry and nimbledroid perf test measure the load time with the presence of the progress bar.  But it may be possible that on webview, the progressbar disappears prior to the loading of every element.  We need to:

1. Identify the difference between webview vs. geckoview in terms of progressbar behavior

2. If they are difference, Geckoview needs to provide hooks so Focus can use that for performance measurement instead.

Comment 1

[Chris Peterson [:cpeterson]]

Performance parity with WebView is a Klar+GeckoView release blocker, so we need to know if the progress bar is causing unexpected test results like bug 1454474.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Meant to leave the comment from 1454474 Comment 2 here. Two similar bugs :(

Summary is that nglayout.initialpaint.delay appears to improve page load. Firefox for Android uses 250ms and desktop uses 5ms. See https://searchfox.org/mozilla-central/source/layout/base/PresShell.h#64

Second finding is that the page appears to be visually loaded long before the progress bar finishes loading.

Comment 3

[No-Jun Park [:njpark]]

On a slower device (Nexus 5 with Android 6.0, for example) complex sites (i.e. buzzfeed.com) are loaded, but the progressbar is stuck on 25%.  This times out nimbledroid tests on Geckoview.  This behavior can be seen on x86 simulator as well.  

This bug blocks the nimbledroid geckoview tests.

Comment 4

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

Randell is comment 3 something you could help us triage further?

Comment 5

[Chris Peterson [:cpeterson]]

ekager says, because GeckoView doesn't provide onProgressChanged callbacks (bug 1437988), Klar's progress bar hard codes GeckoView's onPageStart callback to display 25% and onPageStop to display 99%.

I don't know what triggers Klar to dismiss the progress bar after 99%. On my Moto G5, most websites show 25% progress for a long time and then appear to dismiss the progress bar without showing 99%.

Comment 6

[Vicky Chin [:vchin]]

How do we determine page load is complete in WebView and in GeckoView? 
Is there a signal that's common between both WV and GV that we can use to compare performance? I don't think the progress bar is representative of page load as we've noticed it stays long after the page appears loaded in some cases.

Comment 7

[No-Jun Park [:njpark]]

(In reply to Vicky Chin [:vchin] from comment #6)
> How do we determine page load is complete in WebView and in GeckoView? 
> Is there a signal that's common between both WV and GV that we can use to
> compare performance? I don't think the progress bar is representative of
> page load as we've noticed it stays long after the page appears loaded in
> some cases.

The progressbar seems to be the only method right now to indicate the completion of page load (devs can correct me if I'm mistaken).  The failure to hide progressbar when the page load is completed only happens on older android devices (i.e. API 23 or lower), and this appears to be a bug.  Recently, (since Comment 3) more sites are properly clearing the progressbar on geckoview, but still there are a few sites (i.e. yelp) that have progressbar stuck on 25%.

Comment 8

[Chris Peterson [:cpeterson]]

James is investigating while Eugen is out on PTO.

Comment 9

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

Back to Eugen :)

Comment 10

[Chris Peterson [:cpeterson]]

[geckoview:klar:p1] because this bug breaks the Nimbledroid tests on the Focus+GV.

Comment 11

[Vicky Chin [:vchin]]

Now that 1437988 is fixed what are the next steps? I believe that change is now uplifted to 62. I installed the latest Focus Nightly (not sure if it's in that version though) and still see sites with progress bar differences. Should I open separate bugs to track those issues or append to this one?

Comment 12

[Eugen Sawin [:esawin]]

(In reply to Vicky Chin [:vchin] from comment #11)
> Now that 1437988 is fixed what are the next steps? I believe that change is
> now uplifted to 62. I installed the latest Focus Nightly (not sure if it's
> in that version though) and still see sites with progress bar differences.
> Should I open separate bugs to track those issues or append to this one?

The next step is for Focus to land a patch to use the new onProgressChange API to control the progress bar.

Then we should be able to see changes in the trends on Nimbledroid and use those results to identify individual sites for inspection to confirm that the progress bar corresponds with the visual page load progress.

Based on that research, we can further tweak the progress tracker in GV.

Comment 13

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

I'm liking what I see in Focus+GV nightly :)

Comment 14

[No-Jun Park [:njpark]]

So SV tested all sites manually, and noticed that GV sometimes clears pageload indicator prematurely too.  Sphilp says:
SV manual loads from last week showed the progress bar issue on some sites with geckoview. flipkart.com is a decent example of this - basically appears to be a single page app that "loads" (progress bar disappaears) and then it does it's own xhr/js work after to actually load in the content. the google maps pwa also does (the map itself loads in after progress bar disappears)

Comment 15

[No-Jun Park [:njpark]]

I wonder whether there would be a good way to measure those sites, other than visual verification

(In reply to No-Jun Park [:njpark] from comment #14)
> So SV tested all sites manually, and noticed that GV sometimes clears
> pageload indicator prematurely too.  Sphilp says:
> SV manual loads from last week showed the progress bar issue on some sites
> with geckoview. flipkart.com is a decent example of this - basically appears
> to be a single page app that "loads" (progress bar disappaears) and then it
> does it's own xhr/js work after to actually load in the content. the google
> maps pwa also does (the map itself loads in after progress bar disappears)

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking as wontfix for 62/63 since we are about to ship 63.

Comment 17

[Mark]

I'm sure you guys already know this, but FWIW

Chromium (and WebView?) on some pages complete the progress bar animation long before some page content (JavaScript elements??) pops into view. Fennec & Focus+GeckoView seem more "honest" and the progress bar hangs around until every last element has loaded. The difference is particularly pronounced on slower phones, the perceived load time of Chrome/Chromium can be several seconds shorter than GeckoView just because of this progress bar "hanging around".

Examples:-

www.bbc.co.uk/news - the small gray bell top center of the page. On Chromium the progress bar completes, but the gray bell doesn't appear until 2-3 seconds later. On Focus+GeckoView the progress bar hangs around until the gray bell appears and only disappears afterwards. A big difference in perceived load time.

www.theguardian.com - the weather forecast icon top right, and the little comment icons under each story. Ditto on Chromium the weather icon appears several seconds after the progress bar completes, on Focus+GeckoView the progress bar hangs around until the weather icon appears. 

(on both sites you have to reload a few times and clear all the cookie and begging pop ups to get a clear comparison).

By "Chromium" here I mean Samsung Internet or Edge, they have ad blockers which IMHO puts them more or less on level footing with Focus+GeckoView. I've also tried Lightning Browser which I think uses WebView, same story.

I'm using an old Snapdragon 425 phone, dog slow.

Comment 18

[Chris Peterson [:cpeterson]]

Setting [geckoview] whiteboard tag so we re-triage this bug. A Focus user reported some more sites where Focus+GV's progress bar is open for multiple seconds after the page is visually complete:

https://github.com/mozilla-mobile/focus-android/issues/3622

Comment 19

[Chris Peterson [:cpeterson]]

Removing status flag values since this is a meta bug that won't be fixed in a specific release.

Comment 20

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

FYI, I was testing on eurosport.de (https://health.graphics/android/graph?site=https://www.eurosport.de)
(Note: the jump Nov 13th was when we turned off Tracker blocking on Focus/Klar to allow for apples-to-apples comparison to Chrome, I believe).
Looking at this on my Moto G5, I see huge differences in how complete the page is between Chrome and Focus/GV when the loading bar goes away; chrome's often goes away before much of the content in the page has painted; we wait for basically all of it.

Someone should delve into the Chrome source to find where they decide to remove the loading bar - what blocks it (and what doesn't) so we can compare.

Comment 21

[Mark]

tl;dr version

I took a look at a couple of pages across 3 browsers and tried to time the progress bar visibility and get the total page load time using various hacky methods.

On these two pages, Chrome & Chromium seem to complete and disappear the progress bar roughly half way through the “actual” load time. Fennec OTOH shows the progress bar for the entire “actual” load time. Fennec is slower than Chrome/Chromium on the “actual” load time, but the difference is not as enormous as just relying on the the progress bar might indicate.

my numbers for eurosport.de are broadly similar to the android health graphic link in comment 20.

There seems to be a chrome flag --progress-bar-completion which alters its behaviour. I don’t fully understand but you will:-
https://kapeli.com/cheat_sheets/Chromium_Command_Line_Switches.docset/Contents/Resources/Documents/index
https://www.spicytweaks.com/2017/04/progress-bar-animation-chrome-android.html

Detail

uk.mobile.reuters.com, no tracking protection or ad blockers
                         progress bar       “actual” page
                          disappears          load time
Chrome Beta                  ~5 sec             ~9 sec
Samsung Internet Beta        ~5 sec             ~9 sec
Fennec Nightly              ~11 sec            ~11 sec

eurosport.de, no tracking protection or ad blockers

Chrome Beta                  ~5 sec           ~12  sec
Samsung Internet Beta        ~5 sec           ~11  sec
Fennec Nightly              ~20 sec           ~20 sec

I looked at uk.mobile.reuters.com and eurosport.de on my “slow” phone which is ~your Moto G5. On Chrome Beta with a cleared cache, the progress bar completes after ~5 seconds on both sites. But if I then tap on the three dot menu I see the X icon for stop page load rather than the reload icon. So I think the page is still loading. I pressed and guessed a few times to find when the X turns into the reload icon. I think the total page load time (nearest equivalent to Fennec?) is ~9 seconds for reuters and ~11 seconds for eurosport.de.

I also tried another Chromium browser, Samsung Internet, with no ad blocking.  I got roughly the same figures (I also was able to get LoaderLog start/stop timestamps out of adb which confirmed the numbers.

I also tried Fennec Nightly with no tracking protection or ad blockers. No doubt Fennec is slower than Chrome/Chromium on “actual” page load time, but the actual difference is eg a factor of 1.5x not a factor of 2x or 4x as it might seem from comparing progress bars.

Comment 22

[Mark]

This might be relevant too https://bugs.chromium.org/p/chromium/issues/detail?id=513459

Comment 23

[Chris Peterson [:cpeterson]]

Thanks, Mark. These test results and the Chromium bug are interesting. The progress bars do have a strong psychological impact on perceived performance.

Comment 24

[Mark]

Re psychology

A diatribe against the Fennec/GeckoView progress bar

tl;dr

I think the main purposes of the progress bar are:- to reassure the user that the page load hasn’t stalled; tell them roughly how long until they’re able to read the page; and to make the browser "feel snappy”. I think the Fennec/GV progress bar mostly does the opposite. I think you should adopt a Chromesque solution:-  you’d get a massive psychological speed boost; and I think users would be less confused about what the browser is actually doing.

Detail
 
The Fennec/GV progress bar is bad because

(1) it makes Fennec/GV seem very slow compared to Chrome. From comments above, I think Chrome tries to disappear its progress bar as soon as the page is “useable” i.e. it scrolls OK albeit with jank and pop ins as the rest of the content loads. Which kind of makes sense. And it makes Chrome seem INCREDIBLY fast compared to Fennec/GV. But that’s just perception - I don’t think Chrome is really much faster than Fennec/GV. Plus, Fennec/GV's progress bar hangs around an awful long time not telling the user very much useful ... 

(2) it’s very front end loaded. Using the eurosport.de example on my slow phone with no tracking protection or ad blockers:-  the progress bar goes zoooooom across to ~80% in ~6 seconds which is ~where page is useable. Then it stalls at ~80% for >10 seconds while all the ads, vids and **** load up. That 10 second stall is quite perturbing for the user. It looks like the network or browser has broken. At the very least I think the front end loading should go away, so there is some proportional progress in the progress bar throughout the whole 16 second load rather than 6 second zoooooom then 10 second “stall".

(3) it’s a bright color, and it throbs, which just draws attention to it. Particularly when it’s “stalled” at 80% for many seconds it draws attention to itself by being bright and by throbbing, seemingly saying “look at me, I am stalled ... look at me, I am stalled ... look at me; I am stalled ...”. I don’t think it needs to be bright/throbsome. De-emphasise it, make it dull and unobtrusive

(4) it emphasises the fact that, if you start scrolling the page during the load, the load can take much much longer than if you don’t scroll the page. So it can make Fennec/GV seem even slower, and it discourages users from using the page ASAP. E.g. the Fennec/GV progress bar sits throbbing at 80% for >10 seconds on eurosport.de. If during that time I start to aggressively use the page (eg scrolling) that hits my CPU very hard and it slows the page load down even further. The progress bar can easily hang around for 20 or 30 seconds. If you keep scrolling up and down, the progress bar remains throbbing at 80% more or less indefinitely in a kind of page loading death spiral. This adds even further to the impression that Fennec/GV is very slow compared to Chrome. Which isn’t true.

So, make the progress bar go away as soon as the user can use the page even though it hasn't actually completed loading. Less confusion, angst and a massive apparent speed boost. For "free" ;)

Comment 25

[Mark]

I re-read my last post and it comes across as unnecessarily negative and critical. Sorry!

Comment 26

[Mark]

More comments, could this be a way to emphasise one of Fennec/GV's strengths:- smoother scrolling while the CPU is busy. And de-emphasise one of its weaknesses:- slower page load time.

Chrome Android seems to go through 3 phases:-
1. page not loaded (2-5 seconds); 
   progress bar visible, page not useable, CPU working hard
-> progress bar disappears
2. background loading (many seconds or tens of seconds); 
   page 'apparently loaded', progress bar gone, page useable but some elements not present, CPU working hard
-> stop page load icon turns to reload icon in three dot menu
3. fully loaded (elapsed time 5-30 seconds)
   all elements present, CPU goes idle

Phase 2 can be really really long, particularly if you start to scroll. I bet Chrome Android users spend a significant percentage of their browsing time in Phase 2 without really being aware of it.

Now during Phase 2 Chrome is not that great to use on a low or mid range device. In particular scrolling is janky and there can be scrolling freezes of up to a second. And the more you scroll, the longer Phase 2 gets (because the CPU prioritises scrolling over loading??). Once Chrome moves to Phase 3 it cleans up, the jank mostly goes. Fennec/GV are much nicer in Phase 2, particularly I think with OMTP enabled. All Mozilla's hard work paying off? And I guess WebRender will be even better when it comes.

I think in a Phase 1 or Phase 3 benchmark, Fennec/GV will still fall behind Chrome. Maybe 30%. But Fennec/GV (plus OMTP, WR) could really shine by encouraging users not to think about Phase 1 too much and instead emphasising how great Fennec/GV are in Phase 2. In fact, on Fennec/GV Phase 2 is pretty much indistiguishable from Phase 3. Which is not the case on Chrome on low/mid end devices.

To put it another way, by emphasising the useability during Phase 2 (e.g. by disappearing the progress bar early like Chrome does) you could perhaps get a UX like this:-

"On my Moto G5 in Chrome, the page 'apparently loads' in 3 seconds, but then for the next few seconds or tens of seconds it's a bit janky and occasionally freezes for a second. On Fennec/GV, the same page 'apparently loads' in 4 seconds, but then it's really smooth. On both browsers sometimes I have to stop scrolling and wait a second for my desired image to pop into view [if user is still in Phase 2]".

Cheers now :)

Comment 27

[Chris Peterson [:cpeterson]]

Adding [geckoview:fenix:p1] whiteboard label because we really need to resolve these UX issues with our progress bar. The current behavior makes GV look much slower than Chrome on some sites. The progress bar will linger even after the page is loaded and functional.

Comment 28

[Mark]

Attachment: Fennec progress bar TP vs uBo compressed.m4v

Issue might be related to add-on ad blockers (uBlock Origin etc)???

Video is identical phones / identical Fennec Nightly / identical page (uk.mobile.reuters.com). Left phone uses Tracking Protection, no ad blocker and right phone uses uBlock Origin & TP is off. Right phone shows the progress bar "hang" at 80% for ~3 seconds which left phone doesn't show. Not perfectly apples to apples but phones should be loading substantially the same content, if anything uBO phone should be loading less stuff.

Seems to happen a lot on Reuters pages, don't know about other sites. It's not a universal issue.

I tried replacing uBO with AdBlock Plus and saw substantially the same issue, so I don't think it's uBO per se.

I'll try to dig into profiles etc but it's not exactly my strong point :)

Comment 29

[Mark]

Attachment: Reuters with TP.json

FWIW

Profile captures for same uk.mobile.reuters.com page on same phone with Tracking Protection vs uBlock Origin. When using uBO the progress bar hangs for ~3 seconds at the 80% mark which doesn't happen when using TP. This is on my Galaxy S7 which is pretty fast so 3 seconds is a lot... it really increases the page load time.

Comment 30

[Mark]

Attachment: Reuters with uBO.json

Comment 31

[Chris Peterson [:cpeterson]]

The Fennec Perceived Performance Study made the following recommendations about the page loading progress bar:

• Adjust the timing & duration of the loading bar. Participants were ok with a less accurate loading bar as long as it indicated when the main content, structure, and actions were ready to be interacted with.
• A slower, more accurate loading bar could actually reduce perceived performance.

Comment 32

[Mark]

Great

My suggestions would be

implement the Chrome(ium) style progress bar rules. Fennec suddenly "appears two to three times faster" than it did and much more similar to Chrome(ium). I suspect the perceived speed difference from Chrome(ium) would be pretty small & users would stop bitching about Fennec being slow ... mostly ;)

if you want to get fancy you could tweak the Chrome rules to e.g. "the later of (Chrome rules, first paint)" because for some pages (uk.mobile.reuters.com is an example) the Chrome progress bar completes/disappears before first paint leaving perhaps 1 second of blank screen before the page paints and is useable. Which is not super elegant.

You probably get bug 1413128 fixed for free (or substantially mitigated).

Make sure the X button for stop page load still appears in the toolbar until page load is really completed, and bug 1344517 is correctly handled (I think this will be OK, IIUC the toolbar movement and progress bar animation use different rules)

On Fennec, get rid of the animation to 100% at the end of page load. It takes perhaps 0.5 seconds which adds to the perceived load time. Do what reference-browser does - just disappear the progress bar as soon as the Chrome criterion is met, even if the bar is only at 80% or whatever.

On Fennec, de-emphasise the progress bar as much as possible. Get rid of the continuous throb animation that it has. It should be like the gas gauge in my car: it's there if I need it, but it shouldn't be front and center. The throb just draws attention to how slow my page load is :) . The reference-browser progress bar is much nicer, it's out of my eyeline at the bottom of the screen and it's relatively drab so it's not distracting.

I know Fennec is in maintenance mode so the last two might be not worth the effort for you guys. But if there's anything simple/low risk you can do along those lines I do think it will help.

Really exciting if you can do something along these lines ... I think it would be a massive perceived performance win for (hopefully) not much effort.

Cheers

Comment 33

[Chris Peterson [:cpeterson]]

Eugen says he would like to wait for Vicky's team to add our existing page load telemetry to the performance dashboard. Then we can compare the before and after results when Eugen starts tweaking the load progress events.

Comment 34

[Mark]

Makes sense. Is there a bug I can track for the telemetry stuff?

(aside:- reference-browser allows you to load without seeing the progress bar at all, by keeping the toolbar hidden. It's most disconcerting, looking at a completely blank screen for 3-5 seconds. So definitely need some kind of progress bar at least until first paint or after).

Comment 35

[Eugen Sawin [:esawin]]

Mark, this bug is tracking progress bar behaviour for GeckoView, which does not affect Fennec. Please move the discussion regarding Fennec's progress bar into a different bug.

Comment 36

[Chris Peterson [:cpeterson]]

[geckoview:fenix:m3] not [geckoview:fenix:p1]

Comment 37

[Chris Peterson [:cpeterson]]

Removing [geckoview:fenix:m3] because this is a meta bug that doesn't need to block Fenix MVP.

Comment 38

[Chris Peterson [:cpeterson]]

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:fluffyemily, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 40

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:amoya, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 41

[Chris Peterson [:cpeterson]]

Tasks and enhancements should have severity N/A.