1699501 - Slow reflow on chat.google.com, with deeply nested flexbox

Status: RESOLVED WORKSFORME

(Core :: Layout: Flexbox, defect)

Description

[Daniel Holbert [:dholbert]]

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.)

Comment 1

[Daniel Holbert [:dholbert]]

Here's a zoomed in version of the profile, looking at the 565ms reflow: https://share.firefox.dev/3cNMVoL

Comment 2

[Daniel Holbert [:dholbert]]

ni=me to see if I can reproduce this at this point and/or get anything more actionable...

Comment 3

[Daniel Holbert [:dholbert]]

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 and offsetTop invocations in a script with URL https://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).

Comment 4

[Daniel Holbert [:dholbert]]

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!

Comment 5

[Daniel Holbert [:dholbert]]

(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.)

Comment 6

[Daniel Holbert [:dholbert]]

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).