BUG: Performance issue while dragging component to canvas when you have 2k component on canvas

[mohdSuhailCoditation]

GrapesJS version

• [X] I confirm to use the latest version of GrapesJS

What browser are you using?

Google Chrome Version 101.0.4951.41 (Official Build) (64-bit)

Reproducible demo link

https://jsfiddle.net/Laze0pyg/

Describe the bug

How to reproduce the bug?

1. Add 2k components using the below script.
2. for(let i = 0;i<2000;i++) editor.addComponents('<div>ABC</div>');
3. Try dragging Text Block on to the canvas.

What is the expected behavior? There should be no lag.

What is the current behavior? The green line placeholder is lagging

JS Fiddle https://jsfiddle.net/Laze0pyg/

Demo

https://user-images.githubusercontent.com/100282281/168098195-9b69c333-df8b-43e0-bd64-4f7bee004b48.mp4

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[GedMarc]

but.... add 2000 dom elements with any basic styling to any page and you'll get lag? that might not be the tool, but how the tool is being used?

also check your browser render speed in relation to your pc - http://speed-battle.com/speedtest_e.php

https://www.webfx.com/web-development/learn/why-does-your-website-load-slowly/

In 2015, the average page size was 2MB. That increased in 2016 to 2.3MB. And by 2017, it’s projected to increase to 3MB. But what do those MBs hold?

Your page size is impacted by the images, scripts, HTML, stylesheets, videos, and other elements you may have on a page.

When you have more elements on your page, the page loads more slowly, which can result in a slow website overall if all the pages load like snails.

Solution: Decrease elements per page To decrease the load on your website, decrease the size and quantity of elements on a page.

Consider whether you can achieve your desired effect with fewer photos, videos, or elements overall. I (If you haven’t optimized your images yet, this would be the time!)

If you don’t know whether you have too many elements, perform a heat map test on your website to see what users are viewing and clicking.

For example, if you have a whole page full of your company’s YouTube videos, but the heat map shows that only a quarter are getting clicks, consider removing the videos that aren’t being viewed.

[artf]

Yeah @GedMarc you're right but IMHO the Sorter could be definitely improved in such a case. Right now when the pointer goes over the component (eg. body) the Sorter calculates the dimensions and computed styles of all the children so I can see here a space for improvements. Unfortunately, I don't have any ETA for such improvement, so if anybody wants to explore this path, PRs are welcome.

[noogen]

But then when will it be enough? Slow down at 2k, then next someone report 3k, 5k, 10k, or more ... I know I'm exaggerating but there is such a thing out there called single-page/parallax scrolling website. - My 2c.

Ideas: One thing I've seen from other builder is the idea of block type components. It represent group of components that maybe simple render and only active when goes into edit mode. I know it's probably too much work/rework for grapejs at the moment.

Then again, most of what I've seen usage of grapejs is simple/individual component template or email builder. This include my personal use.

[artf]

But then when will it be enough? Slow down at 2k, then next someone report 3k, 5k, 10k, or more ...

Yeah I mean, the idea is if the HTML page itself is laggy (ml of DOM elements with styles and stuff) there is no point in improving as the editor preview should more or less show what you'd see outside of the editor. But in the case of the demo, you can see how the lag starts only when you activate the component sorter, so that's why I think there is room for improvements.

[mohdSuhailCoditation]

Thanks @artf. I am happy to explore optimisation of sorter.js. It would be really helpful if you could provide some high level pointers and approach for the same.

[lexoyo]

Hi that would be great to optimize this :+1:

I would suggest to use the browser's performance tool, but you probably know this

Thank you for looking into this @mohdSuhailCoditation

[bgrand-ch]

@artf Does GrapesJS use Web Workers, lazy loading or virtual scrolling to optimise the rendering of a list of components or for large component (lots of content with lots of spaces taken)? 🤔

[vizardkill]

https://github.com/GrapesJS/grapesjs/assets/37307788/2d653d49-1a57-458c-bc8c-4833c8c7a690

I have the same problem, and I don't think it is due to the size, I am using the pageManager and I preload an html template and trying to drag new elements to the canvas it happens that the canvas only inserts the component after 10 seconds, it even freezes momentarily

[bgrand-ch]

Hello, I think it would be interesting (but certainly very complex) to implement the following solution:

Load and display components in "virtual scrolling" mode.

If there are no components displayed, display the first X components and pre-load (retrieve, parse, etc.) the next X components in the background.

When scrolling down, display the X pre-loaded components and pre-load the next X components in the background. Remove the first X components when scrolling down.

When scrolling up, do the same process, but in reverse. Display the previous X components and remove the last X components when scrolling up.

@artf What do you think?

[artf]

@vizardkill are you able to create a reproducible demo? Does it happen with all components?

@bgrand-ch Virtualizing the dom makes sense with stuff like a list of items, usually when the size of a single item is known in advance and it's static. Such an approach couldn't work with a generic HTML page where stuff could change the size (eg. JS/CSS) and you might lose the sync with the scrollbar, otherwise, browsers would do such optimization natively.

[bgrand-ch]

@artf As a workaround, I was thinking of preserving the height and the scroll bar by leaving a "placeholder" (an empty div), which is the size of the removed content. 🤔

[MrVibe]

I am facing the exact same issue as described by @vizardkill : https://jumpshare.com/v/Dbsty6qTv5cRXPyJKGfX The reason might be very well connected to the number of items on the page or we are doing the same mistake.