Performance: Atrocious processing performance on news.google.com!
Categories
(Core :: Layout, defect, P2)
Tracking
()
Performance Impact | high |
People
(Reporter: cconover, Unassigned)
References
Details
(Keywords: perf:pageload, Whiteboard: [f72][layout:backlog:78])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
Updated to recent build of Firefox (67), (re-)tested loading a show-all stories on topic link of news.google.com which had previously been 2x slower than Chrome.
Actual results:
With FF 67.0a1, according to the App Telemetry plugin on my 2012 Mac Mini, the processing time was in the order of 17s:
Redirect 0 0
App cache 1 0
DNS lookup 1 0
TCP connection 1 0
TCP request 32 136
TCP response 168 0
Processing 173 17639
onload event 17812 2
This compares with 3.x seconds for Chrome 71.0.3578.98
Redirect 0 0
App cache 7 0
DNS lookup 7 0
TCP connection 7 0
TCP request 17 92
TCP response 109 1772
Processing 114 3610
onload event 3724 0
Expected results:
FF, with its new fancy rendering engine, should not be more than 5x slower than Chrome.
Try it yourself!
Reporter | ||
Comment 1•6 years ago
|
||
Firefox lives and dies based on performance (well first is really not getting totally hacked but...) For 15 years, the perception has been that FF is slow. 57 was a huge step forward, but with issues like this (processing so slow it appears to be locked up), it really brings back into question whether or not FF can compete. In my humble opinion, FF's reputation really hangs on performance. Most people only use a small subset of features of any given product, but what everybody sees, is performance.
Comment 2•6 years ago
|
||
Hi, thanks for your contribution. Tested this issue on Mac OS 10.13.6 I5 Core, windows 10 and Ubuntu 16.04 - on several Firefox versions: nightly 67.0a1, beta 660b5 and release 65.0. On all cases the issue can be reproduced. If more tabs are opened the time of loading increases. A couple of screenshots are added in order to see the time processing. Mention that in other browser as Chris Conover said the time processing is much smaller even more tabs are loaded.
Can you provide me a performance profile ? because on all three machines tested are differences
Comment hidden (obsolete) |
Updated•6 years ago
|
Comment 5•6 years ago
|
||
I'm tagging comment 3 as 'obsolete' so that it autocollapses (and since it's probably not needed, for now).
Here's a profile taken on my linux Thinkpad P50 laptop: https://perfht.ml/2RMJbr9
There are multiple 200-300ms reflows during pageload there that look pretty bad. They're in pretty deeply nested grid/flexbox layout.
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Here's a profile on my 2015 13" MBP:
https://perfht.ml/2ULMP6E
Comment 7•6 years ago
|
||
Yikes! cpearce's profile has a single 14-second reflow operation. (Really, a 14-second call to nsGridContainerFrame::Reflow).
Looking at that profile, it looks like the page has 7 layers of nested CSS Grids, and 6 layers of of nested flex containers. (with other elements interspersed between them)
Comment 8•6 years ago
|
||
We should dupe bug 1524375 to this one, or the other way around. Caching measuring grid reflows the same way we cache the flex ones may be worth it.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 10•6 years ago
|
||
BTW, looking at a profile I did, and a chrome profile, both run all the timeouts at the very, very end of the load. Firefox took ~8 seconds; chrome took ~4 - though chrome was visually complete far earlier than we were. So the timer-deferral stuff isn't hurting us here, and may be helping us slightly
Comment 11•6 years ago
|
||
Hi Mats – Can you please make some time to prioritize and investigate this? Sounds like Emilio's suggestion in comment 8 might be a good approach. But I'd be curious about the level-of-effort here.
Comment 12•6 years ago
|
||
Fwiw, I commented in the dupe: bug 1524375 comment 5.
A wild guess is that it's roughly the same amount of work as for Flexbox.
I probably won't get to this until Q2 at the earliest.
Reporter | ||
Comment 13•6 years ago
|
||
For a really good / bad example (Mueller Report)
Redirect 0 0
App cache 2 0
DNS lookup 2 0
TCP connection 2 0
TCP request 22 90
TCP response 112 0
Processing 120 41384 <---- not good
onload event 41504 1
Safari was much better ~ couple seconds, << 41
Comment 15•5 years ago
|
||
https://perfht.ml/2Vw4rIr profile (on a high-end desktop). 50% of the CPU time is spent in some type of Reflow (2.5 of 5.5s of Web Content CPU). 13s to load in total, though it looks like over half of that was waiting for one googleusercontent load while idle
Daniel is likely right on why the reflow is so bad here
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 17•4 years ago
|
||
Now that we triage by severity, setting this bug's priority to P2 to represent near-term backlog status. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla
Updated•4 years ago
|
Comment 18•4 years ago
|
||
Does the issue still persist? I collected a new profile on high-end laptop https://share.firefox.dev/2ZSW5dw, our reflows seems doing fine now, 30 - 40 ms.
Reporter | ||
Comment 19•4 years ago
|
||
In my re-testing, this is much, much better, feels the same as Chrome now. I don't see any mention of it being fixed -did Google just change their layout, or did someone fix this? Hopefully it is / will be fixed regardless, or it will just pop up again.
Comment 20•4 years ago
|
||
Still an issue. news.google.com hangs Firefox. The status bar says transferring data from www.gstatic.com but it is not an issue with www.gstatic.com. After a very long while it gets past that point then waits at stats.g.doubleclick.net.
Comment 21•4 years ago
|
||
anilnnair, can you use profiler.firefox.com (Firefox Platform
as the setting) to collect a profile for the hangs?
Comment 22•4 years ago
|
||
I think, I figured out how to do that. Here you go: https://share.firefox.dev/2WitRYq
Comment 23•4 years ago
|
||
Thanks - it looks like your profile shows a different piece of code hanging from what this bug was originally focused on, so I've spun off a new bug report to cover your issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1653064
Updated•4 years ago
|
Comment 24•4 years ago
|
||
Comment 25•4 years ago
|
||
sefeng, can you clarify if that range is for things getting better vs. getting worse?
(I'm not sure it makes sense for bug 1617472's patches (the only things in the range you linked) to have any perf impact at all, positive or negative; though emilio can confirm.)
Updated•4 years ago
|
Comment 26•4 years ago
|
||
I meant to say that was the patch which made it better.
Comment 28•4 years ago
|
||
This issue seems resolved as per comment 19.
Comment 29•3 years ago
|
||
Note, we had previously been using this as a "grid reflow is slow and needs optimizing" bug.
bug 1591366 now sort of serves that purpose (for the optimizations that we've currently thought of, at least).
Updated•3 years ago
|
Description
•