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

Status: ASSIGNED

(Core :: Performance, defect)

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.