Slow reflow on chat.google.com, with deeply nested flexbox
Categories
(Core :: Layout: Flexbox, defect)
Tracking
()
Performance Impact | high |
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:responsiveness)
In bug 1698855, we have a profile for jank on chat.google.com, which includes a few slow reflows:
https://share.firefox.dev/3twmYB2
(There's a 178ms reflow in the middle there and a 565ms reflow at the end.)
Reporter | ||
Comment 1•4 years ago
|
||
Here's a zoomed in version of the profile, looking at the 565ms reflow: https://share.firefox.dev/3cNMVoL
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
ni=me to see if I can reproduce this at this point and/or get anything more actionable...
Reporter | ||
Comment 3•3 years ago
|
||
I spent some time profiling this yesterday, and wasn't able to reproduce anything as substantial as the reflows or restyles in the original profile here. (Not sure if my inability-to-repro is due to hardware differences, vs. the site having changed, vs. something else.)
A few notes:
- For pageload purposes, there seems to be a pretty-reasonable cap on the amount of backscroll-content here. (They only load a few scrollports' worth, and then add older stuff lazily with a throbber if you actually scroll to it.)
- I created a microbenchmark using the iframe with the actual chat content, and I timed a full relayout for that document, and we are reliably as-fast-or-faster on Chrome for that task. Specifically, I added this to the top of the html:
<script>
function benchmark() {
var elemToHide = document.documentElement;
elemToHide.style.display = "none";
elemToHide.offsetHeight;
let before = performance.now();
elemToHide.style.display = "";
elemToHide.offsetHeight;
let after = performance.now();
alert(after - before);
}
setTimeout(benchmark, 1000);
</script>
I get values between 20ms and 30ms for both us and Chrome (with some slight variability per time, and with Chrome occasionally reporting values closer to 50ms). I tried a few other variants of the benchmark, e.g. marking the conversation messages as display:none
rather than the whole document; but I couldn't come up with any version where we were reliably slower.
-
When loading the actual site, I did notice that Chrome is still a bit snappier to get to the final rendering (on the order of a half a second faster), but reflow didn't seem to occupy a substantial portion of the time (the longest reflows that I observed were on the order of 20ms, and I only captured 1-2 of those per profile).
-
In the original profile here, the long reflows were being triggered by
getBoundingClientRect
andoffsetTop
invocations in a script with URLhttps://chat.google.com/dm/[something]
; but now, I'm not seeing any network requests with/dm/
in the URL at all when I load Google Chat. And in my own performance profiles from yesterday, my longest ~20ms reflows come from refresh driver ticks rather than scripts.
So I'm wondering if this has gone away. I'm going to request another profile from the original reporter (alex_mayorga from bug 1698855).
Reporter | ||
Comment 4•3 years ago
|
||
Hi Alex: per previous comment, I'm just following up on some slow reflows in the original profile that you posted in bug 1698855 comment 0.
I have a suspicion that the site has changed such that these aren't an issue anymore - would you mind capturing another performance profile of you reloading https://chat.google.com/ a few times and posting it here, to help me confirm this suspicion?
(It's possible https://chat.google.com/ itself is still a bit slower in Firefox than in Chrome, but I'm trying to determine whether this one particular reflow-related part of that is still an issue or not.)
Thank you!
Reporter | ||
Comment 5•3 years ago
|
||
(Looking at related bug 1699500, I see in bug 1699500 comment 7 [7 months ago] that there was indeed a redesign back then which seemed to improve things. Alex's profile from that comment showed one 96ms reflow, inside of a Element.getBoundingClientRect invocation: https://share.firefox.dev/3pZ6HVb . That's a bit slow, though not as bad as the 500+ms reflow in comment 0 here. And I'm wondering if it's perhaps even better now, given my observations in comment 3 & potential additional redesigns/site-changes that may have happened since then.)
Reporter | ||
Comment 6•3 years ago
|
||
For now, I'm closing this as WORKSFORME per my bullet-points in comment 3.
Please reopen if we do uncover any substantial reflow/restyle slowness on current chat.google.com (or file a new bug, if it looks unrelated to what was originally reported here).
Updated•3 years ago
|
Updated•3 years ago
|
Description
•