Editor performance issues when trying to load complex ACF groups on blocks
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- javascript, jquery, php, wordpress
- Domain
- frontend, performance
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Register the dummy block inside the theme's functions.php using the snippet in the gist
- Import the field group from the gist
- Create the new page and insert the content provided in the gist
- Once page is saved, switch the block to the "preview" mode.
- Reload the page, wait for the editor page to load
- Click on the block to open its editor in the right sidebar
- Field group will try to initialize, blocking the browser for several seconds (~6s on my machine).
- 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.
- Dominant language
- PHP
- Stars
- 947
- Forks
- 198
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from AdvancedCustomFields/acf
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AdvancedCustomFields/acf#1056 ·
-
PHP 8.5: "Using null as an array offset" deprecation in ACF_Data::is() when rendering a block with empty data (local-meta.php is_request)Possibly taken @faisalahammad claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AdvancedCustomFields/acf#1044 ·
-
is_preview was called incorrectly notice on every early get_field() since 6.8.10 (acf_revisions::acf_validate_post_id)Possibly taken @faisalahammad claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
AdvancedCustomFields/acf#1041 · 1 comment ·
-
True / False ACF control bug on RTL layoutsPossibly taken @elicohenator claimed this 53 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
AdvancedCustomFields/acf#1038 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
AdvancedCustomFields/acf#1034 · 3 comments ·
All issues in AdvancedCustomFields/acf
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
[Sync EN] Formatting improvements to "Large Objects (LOBs)" docs (#6056)Possibly taken A pull request linked to this issue is open or already merged. Opensync-en
Difficulty 1/5 Under an hour Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Перевод устарел
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
repo:cms
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
craftcms/cms#20613 · 1 comment ·
Maintainers usually reply within 1 day