Slow site editor when navigation block has multiple submenu items

[mmtr]

Description

There is a performance issue in the site editor when editing a template that contains a navigation block with multiple submenu items.

The performance issue is practically unnoticeable by default, but it gets worse when activating plugins that register additional blocks (e.g. CoBlocks or WooCommerce).

Upon bisecting the latest changes, it seems that this is a regression introduced by #67734.

Step-by-step reproduction instructions

• Open the site editor
• Edit the navigation menu
• Add multiple submenu items:

• Save the changes and test the following scenarios.

Scenario 1 – A

• Active plugins: Gutenberg
• The performance issue is practically unnoticeable here.

Screen.Recording.2025-01-24.at.12.14.49.mov

Scenario 1 - B

• Active plugins: Gutenberg, CoBlocks
• The performance issue is way more noticeable now. When hovering a menu item, the submenu is not immediately visible. When selecting a block from the list view, it takes a long time for the block to be selected.

Screen.Recording.2025-01-24.at.12.15.38.mov

Scenario 1 - C

• Active plugins: Gutenberg, WooCommerce
• The site editor is almost unresponsive now. Hovering any block takes a long time to have some effect. Selecting a block from the list view takes an even longer time

Screen.Recording.2025-01-24.at.12.19.14.mov

Scenario 2 – A

• Active plugins: Gutenberg with 8042535 reverted
• Since the issue was practically unnoticeable before, no difference can be observed

Screen.Recording.2025-01-24.at.12.25.44.mov

Scenario 2 - B

• Active plugins: Gutenberg with 8042535 reverted, CoBlocks
• The performance issue is gone

Screen.Recording.2025-01-24.at.12.27.47.mov

Scenario 3 - C

• Active plugins: Gutenberg with 8042535 reverted, WooCommerce
• The performance issue is gone

Screen.Recording.2025-01-24.at.12.29.33.mov

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.7.1, Gutenberg 20.1.0, Twenty Twenty-Three
• Chrome
• Desktop with macOS Sequoia 15.2

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[youknowriad]

cc @Mamaduka just in case it becomes an issue for 6.8 as well. I confirm that I reproduce the issue as well.

[ktmn]

I can produce a performance degradation with WC active in post-editor, only using blocks core/group and core/paragraph.

1. Block structure: core/group nested 20x with 2x core/paragraph blocks in the center.
2. Duplicate it 1 time.
3. Save, reload the page.
4. List view open.
5. Now click on the first paragraph in the editor - list view will unfold all the way open (the blocks duplicated in step 2 can remain closed).
6. In the list view, hover over first paragraph, then second paragraph, back and forth (this adds the is-highlighted class to the blocks, re-rendering them).

Initially it will render promptly, the block that gets hovered and the block that loses hover both render in ~0.3ms (Component):

7. Now wait a little, do something, touch some things, maybe click on the 3rd or 4th paragraph to unfold the other group in the list view, but then close it back up again so the "state" is the same as before, idk what the condition is (maybe an autosave even), but suddenly the performance will tank, when attempting step 6 again.

Now the blocks that receive and lose hover in the list view render significantly longer, ~4ms here:

8. Reload the page, do step 5 and 6 again - it's all snappy again, even though the amount of blocks is the same, the amount of blocks unfolded in the list view is same, etc.

Here are the blocks for testing:

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph -->
<p>Hello world</p>
<!-- /wp:paragraph -->
<!-- wp:paragraph -->
<p>Hello world</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

Some actions can fix it as well, like adding some more blocks, or deleting some, sometimes fixes it for some time, and then it slugs down again. Very odd.

[Mamaduka]

@mmtr, were you able to track down which types of block this affects?

Looking at the Jetpack hotfix PR, it seems the bottleneck is the getBlockParentsByBlockName, a memoized selector that receives a new parents array reference on every call, which can affect the memory.

[mmtr]

@Mamaduka I didn't. I always use the "Submenu" block to check the overall performance because the degradation is immediately noticeable with that block, but I have no idea about other types of block.

My guess is that all blocks that require a specific parent block to be inserted are the ones more affected.

[Mamaduka]

@mmtr created the initial pass for the fix #68898. Let me know if that fixes an issue with WooCommerce.

I think they're more "paper-cut" regressions related to the inserter selector performance. For example, the hasInserterItems also shows up in performance profiles.