Visual metrics: Fenix is slower than Fennec for the site accounts.google.com
Categories
(Core :: Performance, defect)
Tracking
()
Performance Impact | medium |
People
(Reporter: sefeng, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:pageload)
Attachments
(1 file)
1.34 MB,
text/html
|
Details |
+++ This bug was initially created as a clone of Bug #1604258 +++
The test was done by comparing Fennec (68.2.1) and Fenix(20191119043902). For instance, the speedIndex of Fennec is 903.07 and is 1042.73 for Fenix, the differences are noticeable by looking at the video.
Comment 1•5 years ago
•
|
||
Profile: https://bit.ly/33Kg27R (from manual loading of accounts.google.com in Fenix on a Moto G5)
This page has almost no external resources, but it is 1.2MB and contains a gigantic inline <script> and a rather big stylesheet, too. When profiling, I had to disable remote debugging (due to devtools overhead) and I also had to disable the "javascript" profiler feature, so this profile doesn't have JS stacks. With JS stacks, the JS execution time was 3x as high, probably due to bug 1409953. (Profile with JS stacks for comparison: https://bit.ly/2QJnF92 )
The network request shows that the server sends a response for 2.1 seconds. Once we have received all the bytes, we spend 500ms in script parsing, and then 180ms in "script emit". And then 1.1 seconds of actual JS execution (with a 100ms reflow in the middle), and then the first useful paint.
It seems that we could gain 500ms by overlapping JS parsing with the network response. Jorendorff, do we have a bug on streaming JS parsing?
This page also shows up as a problem candidate in Andrew's preliminary Fenix vs Chrome comparisons (see this sheet). In the comparison, Chrome has a visualComplete85 time of 1089ms for this page, and Fenix 1626ms (527ms slower). Those numbers were collected on a Pixel 3, which is much faster than the Moto G5 I used to grab the profiles above. So even if we had streaming JS parsing, the gain from that would probably be a lot less than 500ms on a Pixel 3, so there would still be more work to do to get parity.
Comment 2•5 years ago
|
||
This is the raw source for the page I got when I navigated to accounts.google.com in Fenix.
I obtained with the following curl command line:
curl 'https://accounts.google.com/ServiceLogin?passive=1209600&continue=https%3A%2F%2Faccounts.google.com%2F&followup=https%3A%2F%2Faccounts.google.com%2F&flowName=GlifWebSignIn&flowEntry=ServiceLogin' -H 'User-Agent: Mozilla/5.0 (Android 8.1.0; Mobile; rv:76.0) Gecko/76.0 Firefox/76.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-US,de-DE;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: 1P_JAR=2020-03-17-23; NID=200=W1gedMzXX_qhakjjN7F8-R3CltvjjermmMlPYy0C667z_excJ141coZ9nomYAztG4jBzQp4LwFL4lsqwfIqu5Tgx4YLO5iV0ubV2FIdHJX3X_p6JUEB0lXaMwi77SR40tvObGPSYtZOtgsnnyNL0W_00ZBpsjKCZZWRTSdnWLYw; GAPS=1:I4n-IVm-79pgcoQ_rObGiGBixuxLJQ:_wzT2wFzV43bs8SZ' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: none' -H 'TE: Trailers'
Comment 3•5 years ago
|
||
This is one of the sites where Chrome's redirection time is much better than ours (median of 92 vs median of 201)
https://docs.google.com/spreadsheets/d/19fsUpfvUvV-DKCLPHI7aivygtDtJMqrxV9S9qH0SKhQ/edit#gid=213198796&range=249:249
Comment 4•5 years ago
|
||
Also noticed that Chrome looks to be served 11 resources while Firefox gets 15
https://docs.google.com/spreadsheets/d/19fsUpfvUvV-DKCLPHI7aivygtDtJMqrxV9S9qH0SKhQ/edit#gid=213198796&range=205:205
Comment 5•4 years ago
|
||
(In reply to Andrew Creskey [:acreskey] [he/him] from comment #4)
Also noticed that Chrome looks to be served 11 resources while Firefox gets 15
https://docs.google.com/spreadsheets/d/19fsUpfvUvV-DKCLPHI7aivygtDtJMqrxV9S9qH0SKhQ/edit#gid=213198796&range=205:205
Would the slow down be caused by the extra JS file load, or is it still present even when Firefox is being provided the Chrome version or the opposite?
(In reply to Markus Stange [:mstange] from comment #1)
With JS stacks, the JS execution time was 3x as high, probably due to bug 1409953. (Profile with JS stacks for comparison: https://bit.ly/2QJnF92 )
Is that still an issue?
Updated•4 years ago
|
Comment 6•4 years ago
|
||
From my most recent pageload comparisons, Fenix is now measurably faster than Fennec68 on https://accounts.google.com
:
Fenix Beta Jan 27/2021 is about 11-14% faster on SpeedIndex then Fennec68
https://docs.google.com/spreadsheets/d/18qCiz3SReDgDPwhbYfuDrbnBK1030FuVWGBHWwdgCFY/edit#gid=1766567039&range=54:56
I'll include Fennec68 again in my next comparison (around March 22), but I think we can close this and only re-open if I find new data.
Comment 7•4 years ago
|
||
I'm going to close this, still not seeing any evidence that fennec68 is faster than recent Fenix builds on https://accounts.google.com:
Updated•3 years ago
|
Comment 8•2 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #1)
With JS stacks, the JS execution time was 3x as high, probably due to bug 1409953. (Profile with JS stacks for comparison: https://bit.ly/2QJnF92 )
Is that still an issue?
I don't know.
Description
•