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. (Comparison profile with JS stacks: 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](https://docs.google.com/spreadsheets/d/19fsUpfvUvV-DKCLPHI7aivygtDtJMqrxV9S9qH0SKhQ/edit#gid=315865866)). 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.
Bug 1604260 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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](https://docs.google.com/spreadsheets/d/19fsUpfvUvV-DKCLPHI7aivygtDtJMqrxV9S9qH0SKhQ/edit#gid=315865866)). 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.