1667246 - Fenix loads apple.com 2 seconds slower than Chrome

Status: NEW

(GeckoView :: General, defect, P2)

Description

[Asif Youssuff]

Basic information

Saw a video shared on social media with a test between Brave and Fenix: https://vimeo.com/461247541

Recreated the test with Chrome vs. Fenix on a Moto G XT1031 with WebRender and Warp enabled.

apple.com

chrome - 4.75
firefox - 6.75 seconds

---

More information

Profile URL: https://share.firefox.dev/3i8kCSY

Basic systems configuration:

OS version: Android 5.1

GPU model: Adreno 305

Number of cores: Quad-core 1.2 GHz Cortex-A7

Amount of memory (RAM): 1GB

Thanks so much for your help.

Comment 1

[Markus Stange [:mstange]]

Not reproducible on my Moto G5. Marc, can you test this one too, with a more low-end device?

Comment 2

[Denis Palmeiro [:denispal]]

There is a lot of time spent doing delazification during the JS execution and perhaps this is a bigger bottleneck on much older devices. The work in bug 1662110 may help improve this situation by moving some delazification off thread.

Comment 3

[Alex Thayer [:alexical] (she/her)]

Noted by Bas in bug bash triage: the little animation at the top of the current apple.com page is super janky on FF and very smooth on Chrome. We should investigate what's responsible for the difference.

Comment 4

[Bas Schouten (:bas.schouten)]

Mike, this might be something you're interested in looking into.

Comment 5

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: ff-vs-chrome-apple-com.mp4

I was able to reproduce this on my Moto G5. Across two runs filming the device with a separate device, I saw a diff of 1633.33ms and a diff of 1466.67ms (note: the times aren't super precise). I attached a video of one of the runs.

We recently found a 260-524ms delay before calling GeckoSession.load when hitting enter on the search screen fenix#21530 – that's probably part of this.

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: apple-com-new-layout.mp4

There's a new layout for apple.com. The difference now (for one replicate) is 533ms – I attached a video. This difference might now be entirely explained by the front-end issue where we delay 500ms before calling GeckoSession.load. Unfortunately, with the new layout, that means we probably missed out on the 1-1.5s that might have occurred elsewhere.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

The layout for apple.com changed back so I was able to remeasure. I was not able to reproduce the original delay of > 1s: I found fenix is at most 500ms slower than Chrome. Here are my results (note: with only one replicate):

Scenario	FF delay v. Chrome to first paint	FF delay v. Chrome to visual completeness
1. Type "https://www.apple.com" (no redirect)	100ms	0ms
2. Search by autocomplete "apple.com" (is redirect)	33ms	-200ms
3. Launch new tab, do #2 (no redirect)	500ms	267ms
4. Click link http://apple.com (is redirect)	267ms	33ms
5. Click link https://www.apple.com (no redirect)	400ms	266ms
6. Click link from google.com search results	-33ms	-200ms

Known issues

Expanding upon comment 5, there are two known issues in fenix that cause delays of ~200-500ms. The root cause is that some loading events get scheduled on the main thread but these are blocked by a UI transition of ~200-500ms (note: I never measured this duration in a robust way). https://github.com/mozilla-mobile/fenix/issues/21530#issuecomment-938954112 explains this more thoroughly. The two issues occur:

• because of the front-end code, for most load calls (it's optimized when typing a url on the search screen) https://github.com/mozilla-mobile/fenix/issues/21530
• because of the platform code, when page loads have a redirect bug 1734916

Explanation of results

All in all, I suspect the performance issues I can reproduce on apple.com can be attributed to the two bugs mentioned above. I think we should address them and retest. See below for a more detailed explanation.

I tested a variety of cases to try to work around the known issues:

• Case #1 is expected to have none of the issues and it's results are within the noise, as expected
• Case #2 is expected to have the redirect issue but, curiously, it doesn't perform that way. It could be a fluke
• Case #3 is expected to have the front-end issue and it shows
• Case #4 is expected to have the redirect issue and may or may not have the front-end issue (but with a shorter UI thread blockage): it shows
• Case #5 may or may not have the front-end issue (but with a shorter UI thread blockage): the difference is larger than expected but perhaps explainable but the front-end issue
• Case #6 may or may not have the front-end issue and the redirect issue (but with a shorter UI thread blockage): it doesn't appear it has either, though

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Asif, are you still able to reproduce the 2s delay between fenix and chrome? If so, can you explain what steps you took to reproduce it? I've only reproduced a difference of 200-500ms (on the Moto G5) which I believe I know the cause of.

Note to self: if not, we might have found all the optimizations we can from this issue given the current page content.

Comment 9

[Asif Youssuff]

Michael, at this point, it seems like maybe a 1 second difference. At the very least, it is a lot closer.

Comment 10

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

To summarize, I could originally reproduce 1.5s of the 2s reported here. The page layout changed and I can reproduce 500ms while the OP can reproduce ~1s. I identified a problem – page loads are blocked on UI transitions – with two root causes, one in GV and one in the fenix front-end. The next steps for this bug are to address the two root causes and verify it addresses this original bug. The two dependent issues are:

• https://github.com/mozilla-mobile/fenix/issues/21530#issuecomment-938954112
• bug 1734916

I'll stay assigned to follow-up once the dependent issues are fixed but otherwise this bug is inactive.

Comment 11

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Per comment 10, this bug is staying open to verify the fixed behavior once the dependent bugs are fixed. I think it makes sense for the person fixing bug 1734916 to find an owner to verify the fixed behavior rather than me doing it. As such, I'm going to unassign and move this into GeckoView, where bug 1734916 is. Note that the fenix bug mentioned in comment 10 will also need to be addressed.

Comment 12

[Emily Toop (:fluffyemily)]

Re-triaging due to change in priority for the performance team.

Comment 13

[Chris Peterson [:cpeterson]]

This perf bug depends on bug 1734916 integrating the new Declarative onLoadRequest from bug 1734916.

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Chris Peterson [:cpeterson] from comment #13)

This perf bug depends on bug 1734916 integrating the new Declarative onLoadRequest from bug 1734916.

Depends on bug 1734923 because bug 1734916 was resolved as a duplicate of bug 1734923.

Comment 15

[Frank Doty [:fdoty]]

The Performance Priority Calculator has determined this bug's performance priority to be P2. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.

Platforms: Android
Page load impact: Some
[x] Able to reproduce locally