From what I can tell, the “lagginess” here is due to headers re-rendering, not the animations themselves.
One thing I did introduce that may give the perception of new-slowness is the slide-out animation (this animation was inadvertently removed when we refactored our new header)
Giving some setTimeout breathing room between animation and the rerender work the widget menus are doing seem to make things go a lot smoother, so it’s not the animation itself that’s slow, so my suspicion is it’s the work going on around rerendering the site headers on open/close.
I’m actually wondering if firefox’s handling of animation end promise is firing after the animation is well and truly painted (I had assumed this to be the case when coding the original change), which might explain why it looks smoother than chrome, whereas chrome allows recalculation work to start after the animation’s calculations are done, but before the animation end is painted.
EDIT: I’m adding a pause using our runloop to add the necessary breathing space before animating, this should make the animation feel much smoother: UX: call discourseLater on menu animations by featheredtoast · Pull Request #24168 · discourse/discourse · GitHub