Currently for abcnews.com, Webview takes 6 seconds until the progressbar disappears, while it takes 11.5 seconds for geckoview. (accordoing to Nimbledroid.com) Aside from this, the perceived performance difference is that geckoview is slower on sites with many redirects/links. This bug is to track the work that's being done to match the geckoview performance to that of webview.

Performance parity with WebView is a Klar+GeckoView release blocker. One curious difference in the Nimbledroid test results is that, while GeckoView's network I/O is about the same as WebView's for each site, GeckoView's disk read I/O is 2-10x larger. Klar+WebView test results: https://nimbledroid.com/my_apps/org.mozilla.focus.debug?a=16e2cdf0-9343-48fc-997f-dda61c51d40f Klar+GeckoView test results: https://nimbledroid.com/my_apps/org.mozilla.klar.gecko.debug?a=f6e765e7-4f95-499f-806e-e5033204e65e

Here are ballpark videos using Fennec Nightly. The video is 1/8 speed. I cleared the storage from the Android application info page in both cases. I recommend downloading them and viewing using vlc or similar player. https://drive.google.com/drive/folders/1JA6Js7-ENJWuvVfeEy6B6raMgqfOIeRw slow real Δgo event 62 -> 7.75 go pressed 65 -> 8.125 0.375 navigation start 105 -> 13.125 5.375 first paint 122 -> 15.25 7.5 main image decoded 138 -> 17.25 9.5 log in shown 194 -> 24.25 16.5 progress bar starts final animation 198 -> 24.75 17.0 progress bar completes animation using the desktop values for nglayout.initialpaint.delay seems to improve page load slow real Δgo event 45 -> 5.625 go pressed 47 -> 5.875 0.25 navigation start 75 -> 9.375 3.75 first paint 86 -> 10.75 5.125 main image decoded 106 -> 13.25 7.625 log in shown 155 -> 19.375 13.75 progress bar starts final animation 159 -> 19.875 14.25 progress bar completes animation In both cases there is a significant delay between when visually the page is finished loading and when the loading bar disappears. Using a plain geckoview aarch64 build https://queue.taskcluster.net/v1/task/YTEpwJdCRP20UGh6RxaIIA/runs/0/artifacts/public/build/geckoview_example.apk from https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bb4fe8662ae37b2dd680f2d7383d81e1d3008c5f slow real Δgo event 50 -> 6.25 geckoview foreground 88 -> 11.00 4.75 first paint 109 -> 13.625 7.375 main image decoded 145 -> 18.125 11.875 log in shown

TIL [qf?] will not hit the right queries... changing to [qf]

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

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

See bug 1454477 comment 21 Re the Nimbledroid tests, I don't know what Chrome timestamp gets used for "page load complete". If it's related to the progress bar completing, then I think maybe that is far from an apples-to-apples comparison with Fennec/GV. * Start a page load in Chrome beta, particularly a complicated page that makes Fennec look bad in Nimbledroid e.g. tripadvisor.com * while the page is loading in Chrome beta, tap the 3 dot icon to bring up the menu * watch the X top right ("stop page load" icon) and the progress bar * on a "slow" phone like your Moto G5 the progress bar completes after a few seconds but the X doesn't turn into a "reload" circular arrow icon for ~20 seconds. I think the latter is the event most comparable to Fennec/GV "page load complete" for tripadvisor.co.uk (no tracking protection, no ad blockers, slow phone like your Moto G5) I get progress bar page "fully loaded" disappears Chrome Beta ** ~4 secs ** ~22 secs Fennec Nightly ~30 secs ** ~30 secs ** Items with ** ** around them are the ones I think interesting - is that what's being used in the Nimbledroid table? It looks like it. I think Nimbledroid numbers might mostly be showing this difference between what Chrome & Fennec/GV consider "page load complete"? I think Fennec is some tens of percent slower than Chrome, not an order of magnitude as it might appear from some of the Nimbledroid numbers. I don't know how the Nimbledroid stuff is done so I might be completely wrong. If so, sorry!

OK so I had another look at Chromium. I hope all this waffle is helpful to you. Chrome Beta doesn’t seem to give adb logs of its page loading (you probably know better) but Samsung Internet Beta is a Chromium browser which does. eurosport.de / cleared cache / slow Snapdragon 412 / no ad blockers or tracking protection:- Samsung Internet Beta adb log highlights:- 11-24 13:56:22.461 16677 16677 I chromium: [INFO:navigator_impl.cc(419)] LoaderLog NavigateToEntry : DidStartNavigation ... 11-24 13:56:25.897 18447 18460 I chromium: [INFO:render_view_impl.cc(2950)] recognizeArticle native Time : 0.088ms 11-24 13:56:25.906 16677 16677 I chromium: [INFO:web_contents_impl.cc(4180)] WebContentsImpl::OnDidFinishLoad 11-24 13:56:27.417 16677 16677 I chromium: [INFO:web_contents_impl.cc(4180)] WebContentsImpl::OnDidFinishLoad 11-24 13:56:27.473 16677 16677 I chromium: [INFO:web_contents_impl.cc(4180)] WebContentsImpl::OnDidFinishLoad 11-24 13:56:27.983 16677 16677 I chromium: [INFO:web_contents_impl.cc(4180)] WebContentsImpl::OnDidFinishLoad ... <lots more OnDidFinishLoads> ... 11-24 13:56:33.206 16677 16677 I chromium: [INFO:web_contents_impl.cc(4180)] WebContentsImpl::OnDidFinishLoad 11-24 13:56:33.206 16677 16677 I chromium: [INFO:password_manager.cc(736)] OnPasswordFormsRendered 11-24 13:56:33.206 16677 16677 E chromium: [ERROR:password_manager.cc(690)] CanProvisionalManagerSave No provisional save manager 11-24 13:56:33.231 18447 18460 I chromium: [INFO:render_frame_impl.cc(4113)] LoaderLog didFinishLoad enter 11-24 13:56:33.235 16677 16677 I chromium: [INFO:password_manager.cc(736)] OnPasswordFormsRendered 11-24 13:56:33.236 16677 16677 E chromium: [ERROR:password_manager.cc(690)] CanProvisionalManagerSave No provisional save manager 11-24 13:56:33.239 18447 18460 I chromium: [INFO:render_frame_impl.cc(5324)] LoaderLog didStopLoading enter The progress bar completed and disappeared around the time of the first OnDidFinishLoad, so ~3.5 seconds after DidStartNavigation. I looked at Chrome Beta and a WebView browser (Lightning) and they disappear the progress bar after about the same time. But I think the Samsung Internet Beta didStopLoading event is the equivalent of "page load stop” on Fennec, the point at which Fennec disappears its progress bar:- Samsung Internet Beta: ~11 seconds from DidStartNavigation to didStopLoading I timed Chrome Beta using a stopwatch and watching the X icon in the three dot menu, and I timed a WebView browser (Lightning) using Mk I eyeball, I think this is the "end to end" load time, equivalent to "page load stop" on Fennec:- Chrome Beta, WebView ~11 seconds I ran the same tests on Mozilla stuff and used a stopwatch to get the total page load time (start navigation until progress bar disappears):- Fennec Nightly 2018-11-23: ~18 seconds Focus + GV: ~16 seconds So I think there are a few separate issues - Chrome/Chromium/WebView disappear the progress bar around the time of the first OnDidFinishLoad, which Fennec/GV don’t do - Chrome/Chromium/WebView keep loading the page for a long time after this event - Chrome doesn’t seem to give a final “page loaded” log message, but Samsung Internet Beta & Fennec & GV do - On this final “page loaded” benchmark Fennec/GV take around 50% longer to load than Samsung Internet Beta. - (guess) Nimbledroid is comparing the first OnDidFinishLoad in Chrome/WebView (when the progress bar disappears) with the full page load in GV, a much longer time, so not apples-to-apples????? Hope that’s useful :)

More waffle, sorry. Might be helpful? Some more tests on this, see attached .xlsx for the details. I repeatedly loaded (six times each) some of your health.graphics/android speed test pages using my Snapdragon 412 phone (which I think is similar to your test Moto G5). I tested Fennec Nightly, geckoview_example.apk and Samsung Internet Beta (a Chromium browser). All were the latest versions at 2018-12-02. My numbers often don’t agree with what’s on your health.graphics/android page. For example on http://marvel.wikia.com/wiki/Black_Panther I see Chromium loading in 4 seconds and geckoview_example loading in around 6 seconds, not 16 seconds as you have in health.graphics. Similarly for tripadvisor.co.uk I see 6 seconds for Chromium, 16 seconds for geckoview_example, not 3 and 27 seconds. Thoughts (i) GeckoView & (particularly) Fennec vary wildly in their page load times from load to load. e.g. on six loads of fashionbeans.com Fennec varied between 19 and 45 seconds; GeckoView between 10 and 21 seconds. Occasionally the loads can be much longer, the progress bar “stalls” and remains on screen for perhaps minutes. I think Fennec/GV are struggling to fetch elements from Web servers in a timely fashion (I’m using the wrong terminology I know) i.e. I wonder if some of the slowness is down to Fennec/GV waiting for stuff to download, rather than ability to number crunch the stuff once it’s arrived at the device. Chromium mostly seems more stable from load to load. You can see the same effect on health.graphics/android, the page load time graphs for GeckoView vary a lot from day to day, the graphs for Chrome are smooth horizontal lines. (ii) The Fennec/GeckoView progress bar is disconcerting because of issue (i). It hangs around an awful long time. If the page load “stalls” it can just sit there throbbing for many seconds, even minutes. Which feels like the browser or web page is broken. In a sense that’s true, but in another sense it’s not a big issue because the stall probably means some obscure ad or other small piece of content isn’t present. It shouldn’t affect one’s enjoyment of the page. (iii) the health.graphics/android page load times for Chromium seem too fast. As in comments above, I wonder if the Chromium times are for the progress bar to disappear, which happens much more quickly than the total page load???? (iv) When you’re testing GeckoView for health.graphics/android, which load time should you use for comparison? Average of 10 loads? Fastest/Slowest of 10 loads? etc. (v) Fennec is slower than geckoview_example is slower than Chromium. But because of (i) and (iii) maybe the difference is not as big as health.graphics/android might show. geckoview_example is dramatically faster than Fennec - it takes about half the time to load a page load time in most cases. Hurrah! Why? But Chromium is still faster, up to twice as fast again. I wonder how much issue (ii) - if it’s real - is still affecting load times? hope that’s helpful, sorry for so many words. PS I used adb logcat to get the timing I timed Samsung Internet Beta from "LoaderLog NavigateToEntry : DidStartNavigation" until "LoaderLog didStopLoading enter" I timed Fennec and geckoview_example from “page load start” until "page load stop"

(In reply to Mark from comment #8) > More waffle, sorry. Might be helpful? > > Some more tests on this, see attached .xlsx for the details. Thanks! Your feedback is helpful. > (ii) The Fennec/GeckoView progress bar is disconcerting because of issue > (i). It hangs around an awful long time. If the page load “stalls” it can > just sit there throbbing for many seconds, even minutes. Which feels like > the browser or web page is broken. In a sense that’s true, but in another > sense it’s not a big issue because the stall probably means some obscure ad > or other small piece of content isn’t present. It shouldn’t affect one’s > enjoyment of the page. > > (iii) the health.graphics/android page load times for Chromium seem too > fast. As in comments above, I wonder if the Chromium times are for the > progress bar to disappear, which happens much more quickly than the total > page load???? Yeah. I believe the Nimbledroid tests are measuring the progress bar time. Due to limitation in the Nimbledroid test framework, I don't think it can measure the more precise page load events. That's part of the reason we're updating Firefox desktop's Talos "tp6" page load tests for Android. The progress bar sticks around for minutes definitely sounds like a bug. Perhaps we need to add a time out for the progress bar. > (v) Fennec is slower than geckoview_example is slower than Chromium. But > because of (i) and (iii) maybe the difference is not as big as > health.graphics/android might show. geckoview_example is dramatically faster > than Fennec - it takes about half the time to load a page load time in most > cases. Hurrah! Why? We're not exactly sure why GeckoView is often faster than Fennec. GeckoView uses a separate e10s process so the page download might not be interrupted by the UI. Even the Speedometer benchmark (for DOM and JS, not page load) is faster in GeckoView. :)

(In reply to Chris Peterson [:cpeterson] from comment #9) > The progress bar sticks around for minutes definitely sounds like a bug. > Perhaps we need to add a time out for the progress bar. Yes I think there is a bug. I was just running multiple back to back loads of theguardian.com / Fennec Nightly / tracking protection off / no add ons and after a few loads Fennec repeatedly failed to complete the load, the progress bar stalled indefinitely around 80%. I waited up to 3 minutes and it never completed though the page seemed visually complete. It stalled on every reload attempt until I killed & restarted Fennec after which it was fine. I captured a profile (to follow) I hope it's of some use. I'll see if I can get the same behavior on geckoview_example (GV seems altogether better behaved though).

Perhaps this should be part of bug 1454477? Not sure.