1906726 - Fenix pageload progress bar can take multiple times longer to complete than Chrome (e.g. 50 seconds vs 10 seconds)

Status: RESOLVED FIXED

(Core :: Performance: General, defect, P1)

Description

[Andrew Creskey [:acreskey]]

​​The pageload progress indicator in Fenix can drag on well beyond the point at which the content is loaded and rendered.
Compared to Chrome this can lead to a lower quality user experience as it appears that the page is still loading.

Steps to Reproduce:

To emphasize the impact, ensure you are on a slower network.
For example, the videos attached were made on a network with 3mbps throughput and ~300ms rtt latency.

Load a large top site (e.g. nytimes.com wsj.com etc)
Observe how long it takes for the page load progress bar to complete

Expected Results:

Pageload progress bar completes roughly when page is loaded

Actual Results:

In Fenix the indicator can stall and take up to 50seconds (as in the video)

In Chrome, same network, same site, I am seeing the progress bar complete in about 10 seconds.

System configuration:

Samsung A54

Comment 1

[Andrew Creskey [:acreskey]]

Attachment: fenix_nytimes_part_1_of_2.mov

Fenix loading nytimes on slower network, part 1 of 2 due to file size restrictions.

Comment 2

[Andrew Creskey [:acreskey]]

Attachment: fenix_nytimes_part_2_of_2.mov

Fenix loading nytimes on slower network, part 2 of 2 due to file size restrictions.

Comment 3

[Andrew Creskey [:acreskey]]

Attachment: Chrome_nytimes.mov

Comment 4

[Andrew Creskey [:acreskey]]

The pageload progress bar was a bit faster in this profile, but still about 27 seconds long

https://share.firefox.dev/3zwLSJ4

Comment 5

[Andrew Creskey [:acreskey]]

And a 36 second document load with nsHttp logs as markers
https://share.firefox.dev/4cRmNqK

Comment 6

[Andrew Creskey [:acreskey]]

A Chrome performance trace of the same site, same network is here

And another profiler in the chrome://tracing format is here

Comment 7

[Andrew Creskey [:acreskey]]

Not clear yet, but perhaps Chrome is completing the progress bar on DomContentLoaded?

Comment 8

[Andrew Creskey [:acreskey]]

As Markus pointed out, while the progress bar completed in the Chrome load (comment 6), but the load event had not yet fired.

In this Chrome trace we can see DCL firing just before 12 seconds but the load event not until much later, about 23 seconds.

The progress bar completes much closer to DCL, roughly at around 10-12 seconds.

Comment 9

[Andrew Creskey [:acreskey]]

In bug 1889771 we just increased the maximum parallel http connections on Android from 40 to 128.
We have data from CI and local tests that show (as expected) that one impact of the change is load time being decreased, sometimes by up to 40%.

We should re-test this with the 128 socket change landed.

Comment 10

[Andrew Creskey [:acreskey]]

(In reply to Andrew Creskey [:acreskey] from comment #9)

In bug 1889771 we just increased the maximum parallel http connections on Android from 40 to 128.
We have data from CI and local tests that show (as expected) that one impact of the change is load time being decreased, sometimes by up to 40%.

We should re-test this with the 128 socket change landed.

From local tests on nytimes.com, cnn.com, the slow progress bar is not improved with bug 1889771.

Comment 11

[Andrew Creskey [:acreskey]]

https://cnn.com in particular makes a very good test case.

On the same network, 3mbps throughput and ~300ms rtt latency:

Chrome has the loading progress bar complete in under 10 seconds.
In Fenix, it's about 1 minute or longer.

In this profile, resources continue to trickle in for about 90 seconds, at which point the loading indicator finally completes:
https://share.firefox.dev/3Lv96C0

Comment 12

[Andrew Creskey [:acreskey]]

In bug 1915490 and bug 1915186 we've standardized how we categorize and prioritize trackers between nightly/beta/release.

So retesting this one, but still seeing Chrome complete the progress bar within 10-20 seconds while in Fenix it drags on, sometimes indefinitely.
See video attachments.

Comment 13

[Andrew Creskey [:acreskey]]

Attachment: chrome_cnn_3g_slow.mp4

Chrome loading https://www.cnn.com on a RogersInAbox "3g slow" throttled network.

The progress bar completes in about 18 seconds. (Note that the primary image does not even load).

Comment 14

[Andrew Creskey [:acreskey]]

Attachment: fenix_nightly_cnn_3g_slow_trim.mov

Fenix nightly, 09/11/2024, loading https://www.cnn.com on the same RogersInAbox "3g-slow" configuration.

I had to trim the video to fit within Bugzilla file limits, but the progress doesn't actually complete even though all the visual content has has been loaded and displayed for quite some time.

Comment 15

[Andrew Creskey [:acreskey]]

I tried capturing profiles of the near-infinite progress bar, but when profiling so far I'm seeing it complete at about 34seconds, while the images are loaded at about 19 seconds. Not great, but this isn't the problematic scenario that I see in general, and in the videos.

https://share.firefox.dev/3ZfDWqu

Comment 16

[Andrew Creskey [:acreskey]]

I think good next steps on this one could be to find a scenario where multiple people can reproduce a large difference in progress bar times, Fenix to Chrome.
Perhaps https://www.cnn.com, current Fenix Nightly, with 3g-slow or 3g-fast is that scenario, but it's not clear.

With that determined, we can capture nsHttp:5 and related logs, as well as performance profiles, to understand what's happening.

Comment 17

[Andrew Creskey [:acreskey]]

I'm going to see if this is related to the class-of-service tailing that defers tracking requests.

Comment 18

[Andrew Creskey [:acreskey]]

Disabling tailing doesn't seem to resolve the endless progress bar that I'm seeing.
It does seem to affect android pageload tests in CI though, which I'll summarize in bug 1915866

Comment 19

[Andrew Creskey [:acreskey]]

Collecting some findings and patches of Kaya's

Browser Page Load Progress Bar Completion Comparison
https://docs.google.com/presentation/d/1dZldCss2hDTQO4S8MPgk801GFVnMIVGyDTIL2PgPlT4/edit#sl

And patches that adjust when the geckoview progress bar is completed: at MozAfterPaint and at DomContentLoaded.

Comment 20

[Andrew Creskey [:acreskey]]

I'm going to investigate what's in the document loadgroup and why those resources take 50+ seconds to load.

Comment 21

[Andrew Creskey [:acreskey]]

I've built a test page that highlights the different progress bar behaviours between Chrome Mobile and Fenix:

https://acreskeymoz.github.io/slow/slow_images.html

• There is a long running script that blocks DomContentLoaded (both browsers display the progress bar at about 25%)
• The page contains a medium size image and some larger ones which take multiple seconds to load (two below the fold)
• On DomContentLoaded and the first paint, Chrome completes the progress bar. Images are still loading. This is about 13 seconds before the onload event.
• Fenix waits until the onload event to complete the progress bar.

See attached videos. No network throttling required to reproduce.

Comment 22

[Andrew Creskey [:acreskey]]

Attachment: fenix_slowpage_test.mp4

Fenix loading the test page.

Comment 23

[Andrew Creskey [:acreskey]]

Attachment: chrome_slowpage_test.mp4

Chrome loading the test page.

Comment 24

[Andrew Creskey [:acreskey]]

On desktop, as far as I can tell, both Chrome and Firefox run the throbber until the onload event is fired.

On mobile, I find Chrome's behaviour to give a much better user experience, especially on content-heavy sites on slower networks where the Fenix progress bar can run for over a minute, eg, cnn.

I propose that we try out completing the progress bar after the first MozAfterPaint following DOMContentLoaded (maybe nightly only).

Comment 25

[Andrew Creskey [:acreskey]]

If you're curious as to why Fenix displays the content much sooner on this site, it's because gecko crunches through the long running script, below, about 3x faster than Chrome.

   let n = 1000000000;
   let result = 0;
   for (let i = 0; i < n; i++) {
            result += Math.sqrt(i);
     }

I've updated the test site to output the duration of the script: https://acreskeymoz.github.io/slow/slow_images.html

Comment 26

[Andrew Creskey [:acreskey]]

Let's try a perfetto trace to verify the Chrome behaviour on the test page.

Comment 27

[Andrew Creskey [:acreskey]]

I haven't been able to figure out what Chrome is doing with respect to the Android progress bar from the perfetto trace
(One is here if anyone is interested).

But I've constructed a simpler site that demonstrates the behaviour of both browsers:
https://acreskeymoz.github.io/slow/slow_requests.html

Here’s the observed behavior:

• DOMContentLoaded takes a bit over 5 seconds (due to a script loaded via slowfil.es).
• At DOMContentLoaded/ document interactive, Chrome immediately completes the progress bar.
• A new, slow-loading script (8 seconds) is dynamically added to the document.
• Both browsers reach onload at ~16 seconds.
• In Fenix, the progress bar completes only after onload.

This highlights a discrepancy in progress bar handling between Chrome and Fenix.

I think that for the mobile experience, completing the progress bar on the first paint after DomContentLoaded provides a better experience.

Comment 28

[Andrew Creskey [:acreskey]]

Attachment: fenix_chrome_slow_requests.mp4

We can compare the behaviour of Fenix (left) to Chrome (right) on the slow request test site.

Comment 29

[Andrew Creskey [:acreskey]]

Kaya, unless there are objections can you make a variation of your earlier patches in which we complete the progress bar on the first paint after dom content loaded?
We can land this as nightly-only to give folks more of a chance to try it out.

Comment 30

[Andrew Creskey [:acreskey]]

Attachment: fenix_chrome_slow_requests_async.mp4

https://acreskeymoz.github.io/slow/slow_requests_async.html

Added a test in which the slow loading script after DCL is an async script.
We see the same behaviour -- Fenix waits for onLoad event to complete the progress bar while Chrome completes it on DCL / interactive.

Comment 31

[Kaya [:kaya]]

Attachment: Bug 1906726 - Add a config to control the page load progress bar completion on Android.

The default value for Nightly is set to 2, which completes the page load progress bar at the first MozAfterPaint callback after DOMContentLoaded. The completion on the other channels are kept as it is.

Comment 32

[Andrew Creskey [:acreskey]]

We have a probe that records geckoview page load progress time, but it's not clear to me that values are recorded:
https://dictionary.telemetry.mozilla.org/apps/fenix/metrics/geckoview_page_load_progress_time

Comment 33

[Kaya [:kaya]]

:acreskey, we have a stopwatch that's attached to this metric, that we start and stop according to the page load, here: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#190-192

We start if off when the page load starts, here: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#215

Then, we stop it at several places in GeckoViewProgress (page load finish, error case etc.), here's where a successfull pageStop might have happened that we stop the stopwatch with a successful page load state: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#473

Comment 34

[Andrew Creskey [:acreskey]]

(In reply to Kayacan Kaya [:kaya] from comment #33)

:acreskey, we have a stopwatch that's attached to this metric, that we start and stop according to the page load, here: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#190-192

We start if off when the page load starts, here: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#215

Then, we stop it at several places in GeckoViewProgress (page load finish, error case etc.), here's where a successfull pageStop might have happened that we stop the stopwatch with a successful page load state: https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/mobile/shared/modules/geckoview/GeckoViewProgress.sys.mjs#473

I don't think it's necessary to change the glean stopwatch, since, from what I can tell, it's tracking the document pageload (i.e. leading to onload event).

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18407fa1f137
Add a config to control the page load progress bar completion on Android. r=geckoview-reviewers,ohall

Comment 36

[amarc]

https://hg.mozilla.org/mozilla-central/rev/18407fa1f137