+++ This bug was initially created as a clone of Bug #1556022 +++
I've cloned the bug to track the improvements to AES_Decrypt/Encrypt.

I collected speedof.me download speed results for geckoview_example, Firefox Preview, and Chrome on two android devices, the Pixel 3 and the reference phone, Moto G5.
(Based on Kamyar's observations)

speedof.me results

On the Moto G5, download speeds for Geckoview_example and Fenix are ~40% and ~50% of Chrome's, respectively.

On the Pixel 3, download speeds for Geckoview_example and Fenix are ~84% and ~94% of Chrome's, respectively.

Latency also appears to be lower on Chrome.

There is a short writeup on speedof.me regarding how the tests work:
It downloads progressively larger contiguous files until they take longer than 8 seconds to download. The timing for the last one is used.

I also run some tests where I modified network preferences.
Increasing network.http.max-connections doesn't look to improve gecko download speed.
This makes sense since from looking at what the site does it's fewer resources downloaded, but they are quite large.

I tried increasing others prefs that I thought might possibly impact this:
network.http.max-persistent-connections-per-server
network.http.spdy.default-hpack-buffer (set to 4k on android)
network.http.spdy.push-allowance (set to 32k on android)

These didn't appear to impact the reported speed.
The resources I saw in the dev tools did come through via http/2.

If anyone knows of other configurations that could impact this, let me know and I'm happy to try them.

In the simpleperf profile we see a fair deal of time spent in mozilla::Decoder::DecodeToUTF16 so I added this dependency: Bug 1576617

We should open an evangelism bug to get speedof.me to put XHR into binary mode. If it's trying to measure the network, it's kinda bogus for it to measure the further processing of the bytes, too.

(In reply to Henri Sivonen (:hsivonen) from comment #2)

We should open an evangelism bug to get speedof.me to put XHR into binary mode. If it's trying to measure the network, it's kinda bogus for it to measure the further processing of the bytes, too.

That's a good point. Needinfo'ing myself to reach out to speedof.me and also compare our performance in binary mode.

I've contacted speedof.me by two means, so at the moment I think we'll have to wait until we hear back.

Sean point to me to a version of the test that drops the fancy graphics:
https://speedof.me/api/doc/sample_advanced.html

On the Moto G5, I'm seeing Geckoview_Example report 55 to 60 Mbps while Chrome on the same device is downloading at about 105 Mbps.

I've captured a new profile and the GCM work is more prominent for the majority of the test:
https://perfht.ml/334H346

That profile is spending a lot of time in AES crypto work on the socket thread. So bug 1152625 should help (this bug is already marked as depending on that one).

(In reply to Markus Stange [:mstange] from comment #6)

That profile is spending a lot of time in AES crypto work on the socket thread. So bug 1152625 should help (this bug is already marked as depending on that one).

Yes. Last week, we landed it to m-c. But GV is still 20191004 on Fenix due to bug 1586748.

Although I doesn't have MotoG5, when I test this on my Pixel 2, Fenix Nightly is faster than Chrome for download rate. (Since chrome will crash this test on uploading. So I don't know upload rate).

Since 32-bit GCM implementation is different, I guess that this is same speed as Chrome at least.

acreskey, could you test this on Moto G5 with Fenix Nightly?

m_kato,

Using the Jan 2, 2020 Fenix nightly, the results look great.

I used this test as it doesn't include the graphical elements and Chrome also only very rarely crashes with it:
https://speedof.me/api/doc/sample_advanced.html

Previously with this test, Fenix's reported download rate on Moto G5 was ~50% of Chrome's.
They are now effectively equal:

Moto G5

Browser         Download   Upload 

Fenix Nightly    100.42     20.35
Fenix Nightly    105.61     20.45
Fenix Nightly     98.50     20.10

Chrome (79)      104.08     21.59
Chrome (79)      104.54     21.30
Chrome (79)       97.75     21.44

Nice work. I think this should be closed as fixed.

Thank you for verifying. I close this. Bug 1556022 is still open for non-WR device.