-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Comments
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 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. |
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. |
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. |
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. |
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. |
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 |
@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)? 🤔 |
Rocketfy.Maker.-.Google.Chrome.2023-10-18.23-52-03.mp4I 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 |
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? |
@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. |
@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. 🤔 |
I am facing the exact same issue as described by @vizardkill : https://jumpshare.com/v/Dbsty6qTv5cRXPyJKGfX |
With the latest release, containing the refactor of the Sorter by @mohamedsalem401, the previous demo seems to be working fine now 🥳 |
GrapesJS version
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?
for(let i = 0;i<2000;i++) editor.addComponents('<div>ABC</div>');
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
The text was updated successfully, but these errors were encountered: