All synced patterns are loaded in background - critical slow down of editor

[wpsoul]

Description

Latest WP 6.6 and 6.6.1 have one strange problem. At first, I found that all posts that use synced patterns are loaded very slow. So, to test, I added console.log to all my blocks in plugin. And I was surprised to see that all my blocks from synced patterns (reusable templates) are loaded on all pages (even on those that don't use them in content).

Is it correct? Now all synced patterns are loaded everywhere in editor?

Step-by-step reproduction instructions

1. Create reusable templates (synced patterns) and put there some blocks with console.log
2. Create new page, do not add there any synced pattern
3. Add there any block
4. On first loading - looks fine, you will see 1-2-3 console.log from one block that is on page. But when you click on block, you will see a lot of logs from all blocks from all synced patterns

If site has dynamic blocks (like loop block) in synced patterns, this will make page almost impossible to use because all loops will be loaded at once.

Screenshots, screen recording, code snippet

No response

Environment info

• WP 6.6.1

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

[ktmn]

Same, I have synced patterns that utilize features from 3rd party plugins, for testing reasons. When the plugins are disabled the blocks produce validation errors. So when I go to any page, even where the synced pattern isn't being used, I get console full of errors. Pretty inconvenient during development to get messages about blocks that aren't on the page.

[wpsoul]

Same, I have synced patterns that utilize features from 3rd party plugins, for testing reasons. When the plugins are disabled the blocks produce validation errors. So when I go to any page, even where the synced pattern isn't being used, I get console full of errors. Pretty inconvenient during development to get messages about blocks that aren't on the page.

yes, this is how I found that reusable template is reason of slow editor. I saw a lot of errors in console that have nothing related to blocks on current page

[ramonjd]

These blocks initially come from a REST request I see.

When I refresh the page, I'm seeing all my synced pattern blocks loaded from wp/v2/blocks&context=edit&per_page=100&_locale=user

Subsequently they're coming from the store.

I'd assume they're loaded so they appear in the sidebar:

If so, here's the per_page value that, when I tweak it, changes the per_page from -1/100 to n:

gutenberg/packages/editor/src/components/provider/use-block-editor-settings.js

Line 35 in dd31d29

per_page: -1,

With a value of -1, the query is updated to 100 in the middleware.

It looks like there was some optimization in #58239, but I'm not sure it's related. cc @ellatrix or @jsnajdr if they have time to confirm.

[sparkzsecret]

Hope there's a resolution to this bug soon

[ramonjd]

I'd naively say that the request should take place only when the sidebar, or patterns tab, is opened.

Having stated that, I'm not certain whether the editor needs to load the patterns immediately. Maybe there's another reason. But if not, then yes, it would be worth testing triggering the request later in my opinion.

[wpsoul]

@ramonjd problem is not only in fetching. Now, all patterns are executed. Imagine you have 100 patterns. Now all your pages will have 100 loaded patterns in editor and executed. Of course it will slow down editor. And if you have dynamic data in patterns, page will be almost unusable. It should be top priority to fix this

[ramonjd]

Now, all patterns are executed. Imagine you have 100 patterns. Now all your pages will have 100 loaded patterns in editor and executed.

So, I expect the execution to link directly to the previews that rendered. As far as I can tell, the pattern previews are rendered as required. Here's mine logging to console.trace(), which shows it's rendering to an iframe sandbox.

Kapture.2024-08-14.at.11.19.21.mp4

I might be missing something here, but I can't any other pattern parsing when I load the editor. They're fetched via REST, as mentioned above. cc @kevin940726 who knows more about patterns than I ever will.

On a side note, I'm wondering if pagination could help reduce the load on the browser when using the inserter?

Pagination for previews has existed since: #54007

There's a static value for the number of items per panel

gutenberg/packages/block-editor/src/components/inserter/hooks/use-patterns-paging.js

Line 8 in 46f9fe0

const PAGE_SIZE = 20;

Now, there's probably an argument to perhaps reduce this, or make it tweakable, for themes with very intensive patterns.

[wpsoul]

@ramonjd did you try to console when you click on any block in editor? They are loading on first click on any block for me

[ramonjd]

did you try to console when you click on any block in editor? They are loading on first click on any block for m

Yeah, I clicked all over the place in the editor, and the pattern was only rendered (and therefore the console.log executed) when I loaded the pattern preview in the inserter.

Even when I added the pattern to the editor canvas. 🤔

Are there any other env vars you can add to the description? Or even a test pattern itself?

Thanks!

[wpsoul]

@ramonjd Ok, I made new test on clean site. And you are right, it's working as expected. Then, I switched to site where I had a problem. And .....it's also working as expected. Another mystery. But I see that there are several tickets with the same problem, so, problem exists. We just need to know condition when this happens. At least, I know that it's happening after specific condition and not always

[kevin940726]

Should we close this until we can find the reproduction steps? I think it would be easier if one could reproduce it in a controlled environment like WordPress Playground!

[sathyapulse]

@kevin940726 @ramonjd This is reproducible with 3K+ reusable blocks. We created an issue for the same #64219.

[kevin940726]

@sathyapulse Thank you for referencing the issue, I didn't catch up on that one! 🙇

I can reproduce the issue reported in #64219. To make communication easier, I think we can close this and move the conversation there. Feel free to reopen this if you don't think it's a duplicate!

[ramonjd]

Thanks a lot @kevin940726 and @sathyapulse !