Repository navigation
[6.x] Speed up button groups on large entries - #15765
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request speeds up loading entries with lots of Button Group fields.
Button groups check whether their buttons have wrapped onto a second line, so they can stack vertically instead. Every group checked once when it mounted, then again when its
ResizeObserverfirst fired. Each check toggled a "measuring" state, waited a tick, then readoffsetTop, which forces the browser to recalculate styles. On a customer's entry with 376 button groups, that added up to ~300 forced style recalculations, costing ~3.5 seconds while the entry loads.This PR fixes it by only reading layout inside the
ResizeObservercallback, where the browser has just calculated it anyway, so it's free. The full measurement only runs when the buttons have wrapped, or the group is already stacked.On the customer's entry (43 Bard fields, lots of sets), time until all editors are loaded went from ~9.4s to ~4.9s, and style recalculation went from ~5.4s to ~1.2s.
I've added a browser test which covers groups stacking and unstacking. It passes before and after this change.
Related: #13385