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

[BMM]

That’s the problem we ran into. To build seemingly “simple” on-page elements with a block editor simply bloats the pages. We get it. Block editor is rad, intuitive and fast. The lesson here is page size becomes a major problem. If you think removing tables will hurt your SEO take a look at page speed. When a page gets this bloated there’s no “fix” and that will also damage SEO through page speeds. On pages where SEO isn’t a concern who cares so long as user experience isn’t harmed, but if you expect a search engine to rank the page it’s time to give a hard look at use of block editors because of the bloat.

We were trying to add a small container with 5 logos from brand partners and the result is a container, grid, 5 containers and 5 images. This can be done with a simple table and 5 image tags. While one instance of this isn’t a big deal per se, when you repeat it 50 times in a page because that’s what the page needs, this one small feature cost you in page performance such that our editor became unstable. The problem is our BUSINESS has to shrink to the editor’s limitations. So we did the hard thing and decided to change our design to achieve both business needs and operate within the block editors limits.

It is ONLY fair to say that GP and GB are great products, although we do hope for more features like the containers reflecting the contents. Navigating a page is horribly difficult, like a witch hunt, trying to find the element you want to edit, whereas the Gutenberg editor renames the element to reflect it’s contents so the hierarchy reads much like the page.

All that said if our VA can knock out stunning pages with ease that has a serious cost too.

By splitting up the offending page, that caused this support topic, into 12 pages we of course now have restored lightning fast editor load times restoring productivity. Time will tell if we’ve managed to retain the user experience or maybe it’s improved it?

[konetkonet-gr]

Replying to David here:

Your point is totally understandable. I would add that at this moment i cannot come up with any Theme on the market, other than GP, which would be able to withstand (or even come close enough) such a huge number of blocks and work just fine on the frontend, in order to compliment your work.

Again thank you very much for completing the request we had made a few months ago to add the accordion functionality!

[David]

Thanks for the feedback and input.

BMM,
for image galleries the gallery block is the most sensible option here.
Although GB can do a lot more things, we didn’t build it to replace core blocks that do the right job 🙂

Content listing and navigation – yes this is something high on our list. You will already see our blocks using Dynamic Data do reflect their specific purpose. For Container Blocks i would suggest adding a short HTML anchor to each one as those show in the Block List nav.
If we can figure out a stable way of adding other info here, we will do.

Long Content, my personal view is unfortunately anti that of the SEO standards today where long content is king. Personally i would sooner consumer 12 pages as opposed to one super long page. And to be fair here, the front end perfomance using GenerateBlocks on a super long page would be no different to if i hand coded it. The “Bloat” you mention is only a backend editor issue.

But thanks again for bearing with us whilst we tested, it all helps us to ascertain what we need to do better.

[Author]

Posts