User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

https://github.com/ornicar/lila/issues/5080#issuecomment-932586611 sums it up.

1. open the linked chess game (game2)
2. click on move 1 (d4) in the right hand side move list
3. press right arrow on your keyboard to quickly scroll through and execute all moves

Bad performance was one of several reported issues for lichess.org on Firefox.

I profiled the whole process and the profile can be found here: https://share.firefox.dev/2WDxEmI

There is also an about:support (pw is "firefox" without quotation) here: https://bin.disroot.org/?bab1d72498fc58b6#7YBDpqxYhhvq4vH4smwrpHrdcPRyttewheTX7RBfh99M

Actual results:

On my machine, the above process took around 11 or 12 seconds, animations felt quite choopy at times.

Expected results:

Animations should be smooth and the whole process should be faster. For comparison, Chrome needs about 6 or 7 seconds without much noticable choppiness.

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Additional information as described in https://github.com/ornicar/lila/issues/5080#issuecomment-932702231:

If you narrow the lichess window enough so that the move list moves below the chess board, performance in Firefox increases drastically! It still doesn't feel as smooth as Chrome though. The same effect can be achieved if you click on the hamburger menu (the 3 vertical lines) below the move list and flick on "Inline notation". Crude stop watch measurements:

The profile from comment 0 shows most of the time spent in Layout / Reflow.

Hmm, I'm not sure if I'm seeing the same issue on my machine. It feels quite snappy and my profile looks very different, though I am on a really fast machine: https://share.firefox.dev/3uCC4a2

anaka, could you capture another profile with the "Firefox Platform" preset? The preset can be chosen in a dropdown list inside the panel from the profiler toolbar button.
Also, have you ruled out add-ons as a source of the slowness?

(In reply to Markus Stange [:mstange] from comment #4)

anaka, could you capture another profile with the "Firefox Platform" preset? The preset can be chosen in a dropdown list inside the panel from the profiler toolbar button.

With pleasure. I actually captured two profiles for comparison.

1. default settings on lichess: https://share.firefox.dev/3B4K5XJ
2. "Inline notation" switched on as described above: https://share.firefox.dev/2Yc55h3

Also, have you ruled out add-ons as a source of the slowness?

I guess so. I used a clean install of the latest developer edition with only minimal changes in tracking protection and so on. No 3rd party addons installed.

Thanks! I see grid layout show up in the profile: https://share.firefox.dev/39X4fqw

We recently fixed bug 1591366, which should help with grid layout performance. That bug is fixed in Firefox Nightly (94) but not on Beta 93. Could you check what the performance is like in Nightly?

(In reply to Markus Stange [:mstange] from comment #6)

Thanks! I see grid layout show up in the profile: https://share.firefox.dev/39X4fqw

We recently fixed bug 1591366, which should help with grid layout performance. That bug is fixed in Firefox Nightly (94) but not on Beta 93. Could you check what the performance is like in Nightly?

There is progress indeed, eventhough differences between the two settings remain. Chrome still feels smoother, but that will be hard to quantify.

1. clean nightly, default settings on lichess: https://share.firefox.dev/3A62Jge
2. clean nightly, "Inline notation" switched on again: https://share.firefox.dev/3uHbKvq

That looks quite different indeed. Thanks a lot for testing!

The remaining performance problems seem to be in flexbox layout and in WebRender / compositing.
Profile of the layout part: https://share.firefox.dev/2ZT4zF1
Profile indicating compositor bottlenecks: https://share.firefox.dev/2YeFgMA

Let's make this bug about the flexbox performance. Once that's fixed, we can check if the compositor side is still a problem.

Thanks for the bug report.

I believe the URL to test here is https://lichess.org/SWmnJhnm - let me know if I'm misunderstanding though. I captured a profile of myself holding down "rightarrow" at that URL. Here's my profile: https://share.firefox.dev/3mn6DwG

I do see some reflow operations that are 8-10ms long (probably slower on slower machines; this is on my ThinkPad which is relatively snappy); for example, this one:
https://share.firefox.dev/3Aa3apW

That's definitely near the threshold where we could start looking a little janky.

It looks like these reflows are in reaction to textContent being set, FWIW. I'll try to circle back and see if I can gather a bit more information & see if there's any obvious-redundant stuff going on here.

(In reply to Daniel Holbert [:dholbert] from comment #9)

I believe the URL to test here is https://lichess.org/SWmnJhnm - let me know if I'm misunderstanding though.

You are exactly right.

I do see some reflow operations that are 8-10ms long (probably slower on slower machines; this is on my ThinkPad which is relatively snappy); for example, this one:
https://share.firefox.dev/3Aa3apW

That's definitely near the threshold where we could start looking a little janky.

My machine is slow by todays standards, just 2 physical cores. But Chrome performing well should be an incentive for the best browser to catch up. :)

Let point out once again that enabling "Inline notation" on Lichess increases performance (close to Chrome levels but not entirely for me..). So maybe looking at the differences there helps to pinpoint the issue exactly. As a reminder: at https://lichess.org/SWmnJhnm click on the hamburger menu at the bottom right beneath the move list and click "Inline notation". Actually, now that I tried this again it seems to be enough to just open that menu so that the default-style move list is not displayed anymore. Apparently something in that list that Firefox chokes on.

Thanks - that's helpful. Indeed, just opening that bottom-right hamburger menu (and covering up the textual move chart) seems to be sufficient to avoid the vast majority of reflow work here. So that chart is probably the thing that we're spending time laying out on each incremental move here.

Profile without hamburger menu open: https://share.firefox.dev/3uIGufq (1654ms of samples with "reflow" in backtrace)
Profile with hamburger menu open: https://share.firefox.dev/3iA5a57 (221ms of samples with "reflow" in backtrace)