[Resolved] GenerateBlocks causing gutenberg editor to lag/freeze up/crash, memory thristy

[BMM]

All plugins deactivated except GP and GB and the temp login plugin we are using to allow temp access for you folks.

If needed we can deactivate and set up a user instead.

To restate, we removed about 20 grid blocks that contained 5 containers each that were small logos for partners. This brought the page memory demand down to where the page could be worked on, albeit still laggy.

The problem is we have a long way to go on this page and at some point those logos, and more, need to be put back.

So we’re backpedaling to find a functional state. We can attempt to replace the blocks to recreate the memory demand issue if helpful.

Right now the page is using 1.68gb of memory in its current state. When we move a section container it takes about 2 min for the move to take place and the page become editable again.

Thank you!

[Jean Paiva]

Thank you, I’ll be investigating your site to identify where’s the memory leak, I’ll install the Query monitor plugin, and I’ll remove it after my tests.

[BMM]

Thank you all for the help. Hoping for an easy resolution.

[BMM]

Are we able to work on the website while whatever tracking is happening or are we to stay out?

Thanks

[Jean Paiva]

You guys can work on the site, and re-activate all plugins. I copied your page and I’m debugging the code locally.

It’s a tricky one, cause the page is very big and has many images its hard to isolate things. But we are investigating.

[BMM]

No clue if this related, unrelated or what but using GB 1.7 on the site seems to have caused some sort of copy/paste issue when copying from a donor page to new page. I’m started a topic here, but in removing GB 1.7 and reinstalling 1.6 that officially broke the page that is having the freeze up / lag issue.

Getting pretty crazy up in here lol.

New support topic about this issue: https://generatepress.com/forums/topic/generate-blocks-1-7-bug-when-copying-blocks-from-existing-page-to-new-page/

Deactivating GB 1.6 restores the crashed page.

Some how in crashing the page all the GB container blocks have “lost” their container widths.

I was thankfully able to copy the blocks from the page before it had crashed and save them to a new post. The post is in the private area below. All the containers have lost their width so the page is a royal mess.

[BMM]

Yes the issue is persisent. And now the fear is if we attempt to edit a page that the formatting will become a mess. See attached screenshot of an existing page that was opened to edit and the blocks are messed up.

Notice the shortcode and separator blocks aren’t affected. It’s the container blocks that are having issues.

[BMM]

We are at a point where we need to either get premium support and get moving on our site development or abandon this product for a system or solution that can meet our, at this point, simple needs. We haven’t built by any definition a “large” website….yet. And the problems we’re encountering at this stage are such that either we will need to employ a developer or we will need to shift to a theme which either provides a high level of support for their theme or that simply doesn’t create this issues.

Every day that our site cannot launch is big $$$ lost unfortunately and while we WANT GP and GB to work and had intentions to build a robust site using this system we’re facing serious concerns about our ability to do that without jeopardizing our entire business.

If you can please advise on the status of this support topic, what our options are and what expectations we should have that will help us decide the best course of action.

Thank you for being willing to help and we hope we can find a way to move forward.

Thank you

[BMM]

Looks like container blocks are losing their dimensions likely as a result of doing testing and updating to GB 1.7?

See attached screenshot. This page has not been touched by us today. This change happened in the past hour.

[Tom]

Hi there,

We’ve been reviewing our blocks for memory leaks, but we aren’t finding any. While performance can always be improved, we’re not seeing any specific bugs that can be patched here.

The editor is loading for us, but it is definitely slow: https://www.awesomescreenshot.com/video/15068322?key=2d7ffcf7eb019d8da59671e995ab4f47

The main problem I’m seeing is that you have over 800 blocks on a single page (851 blocks, 151 core images, 89 GB images). While the WordPress block editor is great, I don’t believe it was built to handle this kind of page – the memory each block takes up (from GB, core or any other block plugin) is simply too much. Especially images, as they’re resource-intensive by nature, and you have over 200 of them on a single page.

Of course, you’re free to move on to a different block plugin (or stick with core), but if I had to guess, you will likely end up in the same boat building these kinds of massive pages.

I would highly suggest changing direction to smaller pages whether you continue to use GP/GB or not. It will save you a ton of time and headaches.

I wish I could give you a quick function or something to allow you to build out these pages, but it just isn’t possible with the current state of WordPress unless you’re running a really powerful machine.

Also, I see that you’ve downgraded to 1.6 after updating to 1.7. This can cause issues as there is migration that takes place between versions. You may have to go into “Revisions” and restore a version of the page previous to switching versions around in order to allow the plugin to properly migrate your settings. If you run into any issues updating to 1.7 (like your new topic), it’s much better to leave it as-is instead of downgrading or changing things (especially as it’s a staging site). That will allow us to inspect the root issue and either release a patch to fix it so you don’t have to do anything or provide a fix you can apply. It would be better to backup the site using 1.6 and then perform the update. If you need to downgrade, restore the backup vs. downgrading the plugin.

Waiting on an answer in your other topic (thanks for separating them). That one looks like something we should be able to solve quite easily.

[Tom]

Seeing your most recent post now. This indeed looks like an issue where you updated to 1.7, then downgraded to 1.6. The width attribute was migrated in the new version. You will need to go into “Revisions” for this page and restore the version of the page prior to the 1.7 update.

The blocks still think you’re using 1.7, not 1.6.

[BMM]

Thank you for taking a honest look at this.

Yes, it seems hard to believe that it’s 2023 and WordPress (perhaps the block editor) cannot build a page like this.

All of our other pages of course build, edit and load fast so thus the frustration as it’s concerns us building on a platform where we have to “shrink”(?) to the platform instead of building seemingly(!) content.

The real issue perhaps lies in the blocks and that 851 blocks are needed to build a page like this. We’re obviously looking for ways to reduce blocks.

We’ll take a harder look at this and see which path makes the most sense.

While we’d like to say this page is the exception, pages like this could very well become a part of our regular workflow. A system is only as good as it’s weakest link and it seems we’ve found one.

Thank you for the clarification on the width attribute. Do we need to revert all pages then with the plugin change?

[Tom]

We’re always looking at performance improvements, and I know WordPress is as well. This is definitely the most blocks I’ve ever seen on a page before. My assumption is that this will be an issue in WordPress for a while. I’m not sure how other platforms would handle a page like that, either. I think it would depend on the power of the machine you’re using.

For the width attribute – yes, you want to go into “Revisions” and revert back to a version of the page prior to your 1.7 update.

This will make it so those pages know they are 1.6 blocks, not 1.7 blocks. Then I would take a backup of the site you can easily restore if needed.

Then, update to 1.7. If you find a bug, let me know and I’ll look at it personally to see if it’s something that needs patching.

[konetkonet-gr]

Hello,

From reading this thread i believe you have spotted the problem which is the large number of blocks. We are also using at least 600 blocks (probably more) and we are also experiencing long wait times to load the page when trying to edit it or when trying to transfer blocks around. For instance, on a pretty buffed hosting account on pretty powerful server and 10G network, we have to wait from 30 to 60 seconds every time for the pages to load in the backend so that we can edit them. Whenever WordPress makes autosaves, we have to pause editing for at another 20-30 seconds each time too. On the front-end we are doing good (not perfect but still relatively good).

What other approach would you take to avoid this issue?

For example, due to the fact that GP did not provide so far the ability to create tables within accordion tabs (don’t know if you do now), we used the “Advanced Accordion Block” plugin and ended up adding around 400+ table blocks within 8 accordions. I see that you have now added the Accordion block in the most recent update.

Would migrating from the use of “Advanced Accordion Block” plugin to your Accordion block give us better backend editing experience?
Or should we better use Javascript to create the tables we want (they make use of tooltip too)?

We’ve considered removing the tables to lower the block usage in the pages and make them faster but that would harm our SEO rankings a lot so we considered staying in this state until a solution is found.

[David]

Hi there,

i cannot say whether changing to GB Accordions will have any noticeable improvement to the editor experience. The only way to find out would be to try rebuilding a page using GB. . But the over arching issue raised here seems to be related to the core editor, i am not sure its developers expected it to handle such a large number of blocks.

[Author]

Posts