Interface performance issue related to reusable blocks and inserter

[seriusokhatsky]

Description

This issue appears on most of our websites. Usually, when there are a lot of blocks and custom blocks are on the page and you edit the page for some time.
After extensive testing, I noticed that it is somehow related to the Inserter block and reusable blocks as discussed in this issue #64732

So to reproduce the issue with 2025 theme, I created a simple page with 100 empty rows with inserters. And after doing some random clicks and mouse moves for a minute, I see this interface lag. Then I profiled and noticed that when I move the mouse over the Blocks Tree List, it calls getEntityRecords an enormous number of times and causes this lag. It is just an example, but in real projects I saw a lot of performance lags in different places, and every time I saw these getEntityRecords calls.

Screenshots from the profiler:
https://i.gyazo.com/44316f3e8459f0639568ad193442f3ac.png

@Mamaduka, I tried to make the simplest test here. And maybe you can think that this issue is insignificant. But in combination with more complicated pages and blocks, the interface becomes unusable in some situations.

Step-by-step reproduction instructions

1. Install fresh WP. I replicated this both with Gutenberg plugin and without it.
2. Create a page with ~100 empty rows. Here is a code for this page https://gist.github.com/seriusokhatsky/f47743aa48767b3346ee1501c5a19fee
3. Save and reload
4. Do some random mouse moves and clicks between blocks.
5. Run the Chrome Profiler and do a simple move up and down over the Blocks List. Stop the profiler.
6. Search for getEntityRecords to see how many times it is called. VIDEO: https://gyazo.com/8ca28d5a4cd269030a3cbd88ed1bf41d

HOW TO FIX AND TEST.

1. In the wp-content/plugins/gutenberg-git/packages/editor/src/components/provider/use-block-editor-settings.js add the line as shown on the screenshot return EMPTY_OBJECT; https://i.gyazo.com/3cd214d54d3f4d4b1d9def80e290c0d3.png
2. Repeat steps 4-6.

Screenshots, screen recording, code snippet

No response

Environment info

• Latest WP
• Latest Gutenberg
• Latest Google Chrome

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

[Mamaduka]

Thank you for the detailed report, @seriusokhatsky!

Cc-ing a couple more folks who might be interested in this case. @ellatrix, @jsnajdr, @youknowriad.

[youknowriad]

Would it be possible to add a new performance metric to track this properly? The number of times a selector is called is not an issue in itself. It might lead to issues but I'd rather we measure the degradation first.

Like how can I reproduce lags... Should I add a lot of reusable blocks? What triggers the lags? By following the instructions above, I don't see any lags.

I appreciate the investigation though, there's probably a good solution to extract from this (better load reusable blocks, or memoize something) but first, I want to know how I can track this in our performance dashboard to ensure the fix is correct and that we don't regress later.

[seriusokhatsky]

@youknowriad Thank you for taking a look. Actually, I didn't make any extra steps. It is just a fresh installation with a single page of empty blocks. I will try to make extra tests on how to reproduce it with a minimal configuration and steps and let you know.

And yes, this number is not a problem by itself, but in combination with some other factors may lead to potential bottlenecks. It doesn't make sense to describe examples from my website since there are a lot of custom blocks. So I will focus on the 2025 theme.

[Mamaduka]

I was able to easily reproduce the issue locally with the provided test content and 200 synced patterns, which are leftovers from a different issue.

I want to know how I can track this in our performance dashboard to ensure the fix is correct and that we don't regress later

Maybe we could add something like - "editor stays responsive after x actions and y seconds".

Testing Instructions

1. Create a post or page.
2. Copy test content.
3. Open a list view, and try hovering over various test blocks.
4. Eventually, the editor becomes laggy.
5. Every action is slow, and typing is almost impossible.

P.S. Hovering might have started causing some problems after #63668. I'll do more tests tomorrow.

[seriusokhatsky]

@youknowriad @Mamaduka Also video https://www.loom.com/share/58328be5d2af4506b72aaf16a50f403a

[youknowriad]

Thanks for the follow-ups I appreciate it.

Maybe we could add something like - "editor stays responsive after x actions and y seconds".

"Staying responsive" is subjective. I'd just copy our existing "typing" metric and run it with 200 synced patterns. I think that should probably capture it properly.

[Mamaduka]

i'd just copy our existing "typing" metric and run it with 200 synced patterns. I think that should probably capture it properly.

The number of synced patterns isn't the problem in this particular case. I can't reproduce the same bug with the demo (text-heavy) post, even with 200 patterns. But I can reproduce it with the provided test content after deleting all the synced patterns.

Update

A couple of observations while trying to understand the causes better.

• The __experimentalReusableBlocksSelect/getReusableBlocks function is called frequently for specific blocks. An example of this would be container blocks that render Appenders.
• Using similar selectors in rememo's getDependants callback can be expensive, as it is triggered every time the selector executes.
• We should move tracking the block hovered state out of the block-editor store.

[seriusokhatsky]

Hi @Mamaduka

Is it confirmed to be an issue that should be fixed? Should I expect that it will be fixed soon?

Thank you

[Mamaduka]

Hi, @seriusokhatsky

Yes, it's a confirmed issue, and we'll try to fix it as soon as possible.

@ellatrix, I think your #66817 will be a good start here, as it eliminates a big chunk of __experimentalReusableBlocksSelect/getReusableBlocks calls.

I still wasn't able to track down if (or why) there's a memory leak with rememo's getDependants callbacks for this case. @aduth, what would be the best way to debug memory leaks for this library?