Closed Bug 1217415 Opened 9 years ago Closed 3 years ago

Fennec: navigation within some sites is 3x slower than chrome

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: avih, Unassigned)

References

Details

(Whiteboard: [content perf])

On some sites, the duration between clicking a link until the first content from the new URL is displayed (even if the page is still loading) is considerably slower in Fennec compared to chrome.

This contributes to a slower-thanchrome feeling, even if the overall load time (which I didn't measure) was identical.

I noticed this on wikipedia and ebay, but my impression is that it also happens on other sites - but not all sites.

I tested after clearing the cache on both browsers.

Here's a video which demonstrate clicking the first 5 links of a wikipedia page in Fennec and Chrome after clearing the cache (first 3 links in chrome, then first 5 links in Fennec, then another two links at chrome): https://people.mozilla.org/~ahalachmi/share/content-perf/fennec-slow-nav-wikipedia~2015-10-22.mp4

Frame by frame analysis of this video (timestamps in parenthesis):

>    Fennec                    Chrome
> 1. 3.3s (1.21.7 - 1.25.4)    1.6s (0.29.1 - 0.30.6)
> 2. 1.6s (1.32.6 - 1.34.2)    0.5s (0.38.8 - 0.39.3)
> 3. 1.2s (1.41.8 - 1.43.0)    0.4s (0.48.1 - 0.48.5)
> 4. 1.3s (1.49.7 - 1.51.0)    1.3s (2.17.8 - 2.19.1)
> 5. 3.8s (1.59.3 - 2.03.1)    0.6s (2.26.2 - 2.26.8)

On average, Fennec: 2.2s, Chrome: 0.8s, or 3 times slower...

Tested using:
Fennec: Aurora 43.0a2 API11 2015-09-30
Chrome: 39.0.2171.93
This sounds like a general performance issue so I'm not sure it's actionable without more specific details.

Snorp, anything to do here?
Flags: needinfo?(snorp)
(In reply to Michael Comella (:mcomella) from comment #1)
> This sounds like a general performance issue so I'm not sure it's actionable
> without more specific details.

Are you suggesting that even if a good STR exists, and others can reproduce it (not confirmed yet), then the bug should still be dismissed unless whoever filed the bug is able to point at the responsible module or piece of code?
(In reply to Avi Halachmi (:avih) from comment #2)
> Are you suggesting that even if a good STR exists, and others can reproduce
> it (not confirmed yet), then the bug should still be dismissed unless
> whoever filed the bug is able to point at the responsible module or piece of
> code?

No – "this is slow" is actionable to the extent that we need to find out more information about why it is slow. I don't work on the platform code and generally don't have the context to get this information, so I asked for snorp's input.
Yup, figuring some of this out is something we're working on. There are a lot of factors involved.
Flags: needinfo?(snorp)
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.