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

NEW
Unassigned

Status

()

Firefox for Android
General
2 years ago
2 years ago

People

(Reporter: avih, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [content perf])

(Reporter)

Description

2 years ago
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)
(Reporter)

Comment 2

2 years ago
(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)
You need to log in before you can comment on or make changes to this bug.