Editor performance issues when trying to load complex ACF groups on blocks

Describe the bug
ACF is blocking the browser when attempting to initialize the editor fields for ACF block with complex field group and a lot of content inside of it.

This "blocking" is only happening when trying to initialize the block's fields after the page was already loaded. Also, blocking time is way smaller on Firefox.

To Reproduce
Reproduction requires the ACF & ACF Pro plugins to be installed.

1. Register the dummy block inside the theme's functions.php using the snippet in the gist
2. Import the field group from the gist
3. Create the new page and insert the content provided in the gist
4. Once page is saved, switch the block to the "preview" mode.
5. Reload the page, wait for the editor page to load
6. Click on the block to open its editor in the right sidebar
7. Field group will try to initialize, blocking the browser for several seconds (~6s on my machine).
8. After this initial blocking, editor functions normally

Expected behavior
Block fields groups should load near-instantly without blocking the whole browser for several seconds.

Screenshots or Video
Video preview of the lag when clicking on the ACF block and loading the field group:

https://github.com/user-attachments/assets/7ae1f0e8-45b2-41f3-a45c-099ed211700b

Using Chrome DevTools, I've captured the following monstrosity of the "Long Task":

Code
ACF field group, code for creating the dummy block and the content of the page required for reproduction can be found in this gist: https://gist.github.com/koloml/00a529c3ce935753c5e481b0c1898ab3

Version Information:

• WordPress Version: 6.8.1
• PHP Version: 8.2.27
• ACF PRO Version: 6.5.0.1
• Browser: Chrome 139

Additional context
I've tried to analyze the profile results. As you might have seen, the issue lies in the styles recalculation constantly being triggered while field group is rendering itself. Some fields are editing the styles, invalidating the browser internal caches related to styling. Then other fields are requesting the browser to calculate some properties which are dependent on the styling. Browser then recalculates styles and fields are invalidating the styles again.

Here are my attempts to pin-point the causes of the issues from the reproduction.

Checkbox (true_false) on render() is trying to calculate width of .acf-switch-on and .acf-switch-off. JQuery then attempts to get this width and causes browser to recalculate styles. Resulting width is added to inline styles.

Selector (select) with stylized UI enabled is initializing Select2 instance. During dropdown initialization, Select2 tries to subscribe to mousewheel events. This triggers special hook which calculates the line height for the options. During the calculation, it tries to request the font size on one of the parent elements.

I'm pretty sure this does not cover all blocks that cause this issue. I think, at least the fields which are based on Select2 or which are using jQuery in some way might also trigger unnecessary styling recalculations.

Reproduce the case using the theme functions.php block, field group, and post content from the linked gist, then profile initialization when the block opens in the sidebar. Start with the true_false render path and the Select2-based select initialization described in the report, focusing on repeated style recalculation. Done means complex ACF block fields initialize without several seconds of browser blocking.