Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 tasks done
mohdSuhailCoditation opened this issue May 12, 2022 · 12 comments

Comments

@mohdSuhailCoditation
Copy link

mohdSuhailCoditation commented May 12, 2022

GrapesJS version

  • 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

performance_issue.mp4

Code of Conduct

  • I agree to follow this project's Code of Conduct
@GedMarc
Copy link

GedMarc commented May 12, 2022

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
Copy link
Member

artf commented May 13, 2022

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
Copy link

noogen commented May 13, 2022

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
Copy link
Member

artf commented May 13, 2022

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
Copy link
Author

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
Copy link
Contributor

lexoyo commented May 21, 2022

Hi that would be great to optimize this 👍

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

Thank you for looking into this @mohdSuhailCoditation

@bgrand-ch
Copy link
Contributor

bgrand-ch commented Sep 26, 2023

@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
Copy link

Rocketfy.Maker.-.Google.Chrome.2023-10-18.23-52-03.mp4

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
Copy link
Contributor

bgrand-ch commented Oct 19, 2023

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
Copy link
Member

artf commented Oct 19, 2023

@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
Copy link
Contributor

@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
Copy link

MrVibe commented May 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants