Just curious, how much memory is being used when you are editing that page (Inspect in Chrome and visit the memory tab) and experiencing the issue?
@boldfish @digitalgravy and all…
I can 100% Confirm this!
In brief, If you have many elements with/without a framework like ACSS/OxyProps etc…
It will be very laggy.
How to fix it? I come across one solution that makes it do the work very fast.
i.e.
If you edit the home page and have these sections 
Hero, Testimonials, Blog, About…
Don’t do it all at once on the home page, Do this instead:
Design/Develop Each section in Bricks templates separately. Once you are finished, group them on the page you want. Just like you do with the Header and Footer.
The results for me: Bricks Works Fast, Efficiently… NO LAG as for now with the above method.
2 Likes
Sure, but nobody wants to do that. And Bricks doesn’t want that to be the experience people have.
4 Likes
Question - I’m building out my first site using Bricks along with ACSS & Frames, and the lag is driving me nuts… On a Mac is there a browser that might work better than others? I’ve been flipping through Firefox, Safari, Brave, etc. and is any one better than another when it comes to the lag? The site I’m working on is not complex, and I have a few much bigger, complex sites coming, and had hoped to use Bricks, but with this lag…
1 Like
I prefer Chrome/Brave over other browsers when building with Bricks.
As for now, for the lag issue and complex sites/pages, The answer above made me work better till they fix this—just a suggestion.
i still hope to get any update about progress soon.
2 Likes
I am on a Mac mini M1 with 16 gigs of RAM and I experience memory issues with many programs, not just WordPress/Bricks/ACSS/Frames, etc. Once I clear stuff out, there is no lag.
The biggest problem is when I have 50+ tabs open in Chrome, Firefox or Safari. I would suggest using Activity Monitor to check for the offending app on a Mac.
asking again about any update. thanks
2 Likes
I am also experiencing serious lag related to Frames. It appears even with one or two sections on the page. Not related to DOM size. I have Mac M1, 16 GB ram, using updated Chrome on localhost by Local flywheel, php 8, apache server, bricks 1.6.1. If you could not replicate this issue I am eventually willing to set up it online for your remote access if you wish.
I had no lagging even with huge DOM and lots of repeaters when testing without acss and frames…
I would appreciate any official info about progressing the investigation. Thank you! @timmse
1 Like
1.62 and no mention for that topic.
@thomas and @timmse It would be really nice and transparent if you would at least write something about it.
The problem has not only existed for two weeks, there is additonal an internal support ticket where nothing has happened since the last answer and the impact on the daily work is extremely high.
I don’t ask for a fixed date or “will be solved in n weeks” but simply “we have this in the backlog, the problem is moderately complex and we are working on a solution”. Because not even that comes back and that frustrates me.
3 Likes
Hey guys 
Really sorry about the missing response from our side in this thread.
I can confirm the lag when editing complex pages in the builder. As I can reproduce it without any other plugins active it is something we need to fix in core.
We are already working on a fix, but it is much more complex and takes more time than initially anticipated.
I will share a link here with everyone as soon as we got a testable fix for you. So we can hopefully ship it with the next scheduled release.
If anyone is experiencing a lag on non-complex pages, even without any other plugins active, please send us a technical support email to help@bricksbuilder.io as the fix we will tackle in this thread is in regard to editing complex pages in Bricks (read: lots of Bricks elements on a page).
Cheers,
Thomas
24 Likes
nice. and hopefully it will also fix for those facing same issue with only one section added.
1 Like
any infos on this? since all other speed thread getting closed now? thanks!
just one input. since i see its not lagging that intense on mac system. may it be the case bricks is developed on a mac, and only partial checked on windows systems? so lag could come from windows itself?
Way off dude, I have mac, Linux and windows workstations and its the same on all platforms.
1 Like
ok. thanks for the insight. was just obviously happening here. and since its still not clear if and how we could help i tried with some infos 
The only solution is not to use these CSS tools.
Having been really annoyed by the performance lags with ACSS and Frames i’ve started to build a website just with Bricks. So everything is defined in Bricks. At the moment i use around 50 CSS classes that i’ve defined myself. The Bricks interface is snappy and fast, even on long templates, posts and pages. And the best: i can use Firefox.
Downside: creating templates takes longer.
1 Like
That makes no real difference on my instances.
1 Like
I think a great improvement in performance can be made when the updates of the virtual DOM (live preview area) get debounced. Especially when typing (ACSS) variables (like ‘var(–space-m)’, etc), there’s a huge delay between the actual keystroke and the character being typed in the active input field.
Because these changes to these values aren’t being debounced, the builder wants to update every single keystroke. And because incomplete CSS variables cause the other CSS rules to be invalid, the virtual DOM has to re-render a lot of elements. This causes a huge workload for the browser on every single keystroke. For example, when typing ‘var(–space-m)’, the DOM refreshes at least 14 times, and 13 times a large part of the CSS is invalid, causing significant performance issues. Debouncing the value changes somewhere between 200-500ms (on average, 1 keystroke takes 167ms) would make a huge difference.
Another solution which doesn’t use debouncing could be validating the input values. E.g., when an invalid / incomplete CSS property is entered (like ‘var(–spa’), the virtual DOM shouldn’t update / use that value. However, this requires an extra form of input validation, which would most likely cost much more time to implement than the deboucing improvement would take.
I’m going to forward these findings per mail to the Bricks team as well, as this would probably be an enormous improvement to the builder performance.
10 Likes