Slow site editor when navigation block has multiple submenu items #68875

Activity

1. mmtr

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   on Jan 24, 2025
2. youknowriad commented on Jan 24, 2025

   

   youknowriad

   on Jan 24, 2025

   Contributor

   More actions

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

   👍React with 👍1Reacted by George Mamadashvili
3. ktmn commented on Jan 24, 2025

   

   ktmn

   on Jan 24, 2025

   More actions

   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.

   👀React with 👀1Reacted by George Mamadashvili
4. t-hamano

   added

   [Type] PerformanceRelated to performance effortsRelated to performance efforts

   [Block] NavigationAffects the Navigation BlockAffects the Navigation Block

   on Jan 25, 2025
5. t-hamano

   added this to WordPress 6.8 Editor Taskson Jan 25, 2025
6. Mamaduka

   moved this to 📥 Todo in WordPress 6.8 Editor Taskson Jan 27, 2025
7. Mamaduka commented on Jan 27, 2025

   

   Mamaduka

   on Jan 27, 2025

   Member

   More actions

   @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.
8. Mamaduka

   self-assigned this

   on Jan 27, 2025
9. mmtr commented on Jan 27, 2025

   

   mmtr

   on Jan 27, 2025

   ContributorAuthor

   More actions

   @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.

   👍React with 👍1Reacted by George Mamadashvili
10. github-actions

    added

    [Status] In ProgressTracking issues with work in progressTracking issues with work in progress

    on Jan 27, 2025
11. Mamaduka commented on Jan 27, 2025

    

    Mamaduka

    on Jan 27, 2025

    Member

    More actions

    @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.

    ❤️React with ❤️1Reacted by Miguel Torres
12. mmtr commented on Jan 28, 2025

    

    mmtr

    on Jan 28, 2025

    Last edited by mmtr

    ContributorAuthor

    More actions

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

    It does!

    Screen.Recording.2025-01-28.at.13.09.36.mov

    🎉React with 🎉1Reacted by George Mamadashvili
13. Mamaduka

    closed this as completedin #68898on Jan 28, 2025
14. github-project-automation

    moved this from 📥 Todo to ✅ Done in WordPress 6.8 Editor Taskson Jan 28, 2025