Hi Matt,
Thanks for taking interest. Do you use Automatic CSS in those builds?
Had the issue with massive delay switching between classes on an element today.
Issue happened after importing a template onto the page from the frames library (Site using frames & ACSS). There is only 3 sections on the page and not a complex layout.
Made a recording in the performance tab of devtools when switching between the 2 classes on a basic text element.
First is on the imported template from frames
Second is on a basic text element added from the in builder elements panel with the same classes applied to it - and switching back and forth 2 times
seems to be a huge difference in heap size and function execution time for some reason.
saved the JSON file of the recording for both to review in devtools if youâd like me to send them on.
I duplicated the frames element that was causing the slowdown switching between classes and there is no lag switching between the two on the duplicated element on the same page.
Issue is still happening on the original template but working fine on all other instances of the classes on the page.
I have tried selecting the class with frames and ACSS disabled and it is still slow to select / deselect the class on the original but fine on the other instances.
Created a second page and imported (using remote template box) the same template that was causing slowdown on the original and duplicated the element a number of times - no slowdown on switching between classes on any instance on this second page.
Hope that makes sense / is of some use.
1 Like
Nope, nbot using ACSS and AT together. I bought ACSS a couple months ago but still havenât gotten around to implementing it. However, right after I bought it, I did test it and that was when I opened this topic. Iâm still not sure if having ACSS and AT on at the same time might trigger delays/lagging and havenât since had a chance to explore this further.
I got a few responses from Tony and Kevin in November, hope they donât mind me quoting:
âWe ran many many tests. ACSS is not the issue, but it highlights the issue as Bricks is saving state on all the global classes and so on. Itâs just javascript in the browser at the end of the day. [âŠ] using ACSS is likely to show up resource weaknesses as there are a lot of moving parts.â
âOn a blank install, I donât notice a difference when ACSS is active versus not. users will start to experience lag as the DOM of the page being edited gets more complex. We are able to reproduce this lag without ACSS as well.â
1 Like
This is exactly what is happening. The more elements you add on a page, the more profound the issue becomes. Something to do with global classes handling? It certainly needs investigation.
Regarding my site, Maxime installed another version of AT (to test) and here is what I found out after testing it. My answer to him:
"I tested Superpower CSS and indeed without ACSS it is better performance wise. With ACSS on (even slimmed down quite a bit after disabling what I donât use) it is still laggy.
Yet, I also found out the Bricks native Global Class manager is laggy as hell on its own when ACSS is enabled. On the contrary, AT Global Class manager is working properly and is very fast even with ACSS on.
Something else that we could consider is that all ACSS classes (over 2300) appear on the Global Class manager even though I have disabled a lot â this is will be fixed in ACSS 3.0, they will hide them. If hiding means performance improvements too besides UX I remains to be seen â I only hope that Bricks stops searching for them if they are hidden because I suspect this is also connected to the classes related lag(s).
For now, Bricks slows down when a large number of global classes exist in their database or certainly with ACSS classes to be precise â someone needs to test with another framework or with custom classes (a lot over 1000) and see if it slows down too. I donât know, taking guesses here.
For sure though, the structure panel adding/cloning/renaming needs fixing. The Superpower CSS feature lag is certainly related to the general Bricks lag (as in the global class manager) when ACSS on with its 2300+ classes. I am eagerly waiting for ACSS 3.0 to see if hiding unused classes improves things and also any updates from Bricks for the elements related lag in structure panel. "
What I see seems to be in line with âKevinâ & âTonyâ from ACSS. The issue appears only after the DOM gets more complex. It looks like Brikcs is âqueryingâ, âpingingâ, donât know, I am not a developer, all those classes whether they are in use or not. Thatâs why someone needs to test with other frameworks or with over 1000-2000 global classes and see what happens. I donât think there is something in ACSS plugin besides the number of Global Classes that causes delays. I have used a lot heavier plugins (i.e. Bricksforge) and either on or off there is no difference.
1 Like
In that case, I assume the same thing happens with CoreFramework classes
CoreFramework has only around 900 by default. (if you have all the utility classes enabled).
1 Like
The thing is that performance degrades as more and more classes are added in a page because i simple layouts/pages the issue is less profound. I am not saying we need 1.000.000 classes (obviously) but 500-1000 in total for very big projects should not be out of question. I am working with a client now that will end up with over 100 pages some connected to external services (dynamic data), full of gsap animations (they want it) and other dynamic areas too. It is an educational institution. It is all custom so in the end CSS classes pile up and also working without a framework becomes a nightmare.
Right now having that many classes in the database is something the current system does not handle fast. Testing this without ACSS is hard since there are not other frameworks with that many, nor are there many frameworks out there with the same scope - built with a professional page builder in mind. For me it is a must, for others it might not be and this is not the appropriate thread to discuss this.
I have invested a lot of time in âBricks Ecosystemâ now since I strongly believe its the best builder out there for WordPress. However, performance is essential for our workflow and right now it is slowing things down thatâs why I keep on posting and trying to help resolve this (although not a developer)âŠI am really glad that Bricks team is on it and in the end it will get resolved. Great things require patience and hard workâŠ
6 Likes
I have the same problem with ACSS installed. The global class manager is very slow. To search classes, remove or assign class. Also the structure panel is very slow with renaming items etc.
See here: Recording #16
I saw on the Bricks forum that there is an other post about the structure panel bad performance they say it is related to dynamic data. But I donât have dynamic data om the page. The page I have problems with the classes and structure panel. Has a Tabs elements with quite some nested blocks(cards).
I have a really good server and PC both have a lot of ram and cpu.
2 Likes
Anyone tried the new Beta 1.9.8? I am still having lag with structure panel 
. The Global Class manager is laggy too although I use Advanced Themer Global Class manager which works really fast. Maybe the way it loads classes makes the difference.
The change log mentions that the rename lag is fixed but I still see it. Duplication of elements or quickly adding elements also lags. Please do something this is killing our productivity. I lost so much time yesterday on a site with the structure panel lag.
1 Like
Iâm still struggling with the laggy problem as well. I tried on different computers, browsers, servers, I made new installations of WP and Bricks, and if I have a more complex layout, when I duplicate a section, it is very slow.
Screen recording: clean install of WP on InstaWP, Bricks 1.9.8 and the latest Automatic CSS and Frames (itâs the same without these two plugins):
I have been testing more. I can see an improvement to the structure panel operations to be honest but there is still lag.
The lag becomes apparent when I add components with Javascript. For example Tabs/Accordions. And there is a CPU spike on the specific browser tab that I had not noticed because it does not effect my PC use (I have many CPU cores and 64GB Ram).
I have tested only in Firefox with the new Beta but will also check Chrome although it did not make a difference before.
Will report back when I have done more testing. Need to get some work done too.
I tested further and however with the Automatic CSS plugin disabled it is faster, although it still stutters a bit. It appears that the problem is caused by the large number of css classes.
Here a video first without ACSS and then with it enabled:
https://jam.dev/c/96bfcf40-76b0-479b-9c95-e61b9f44d69a
For comparison, hereâs what copying a section looks like in:
Breakdance
https://jam.dev/c/9104a228-ba66-4928-a5ef-f640ca5845f4
immediately, no laggs
Divi
https://jam.dev/c/d418812a-2d1e-41a5-8030-beb4cc4d136d
the same, a copy of the section is created almost immediately.
Unfortunately, in this version bricks is almost unusable for me, not only copying sections gets stuck, but almost all other activities also, even scrolling the page in the builder gets stuck and skips. This worries me even more because after the last update there is no improvement.
Several features of Advanced Themer also come to a crawl like CSS Grid Builder, Box Shadow Generator (using Javascript).
In general, elements with Javascript such as Tabs & Accordions make matters worse because something gets stuck in the Javascript processing in the Browser. I noticed that the builder browser windows is getting CPU spikes. Had not noticed it since besides the specific windows all the rest are responsive.
Weâve fixed this issue in Bricks 1.9.8 beta, now available as a manual download in your account (see changelog).
As with any beta release, please do not use it on a production or live website. It is only meant for testing in a local or staging environment.
@Jargon: Your issue appears more unique, particularly tied to global classes, though it seems to be much worse on your setup. Iâve emailed you some of my observations to further look into it.
@batorbator: Thank you for creating a new thread about global classes. Please discuss any lag related to a large number of classes on this thread: WIP: Builder lags with a large number of classes.
Regarding the elements duplication lag specifically, it is a separate issue we are already aware of. While it gets worse with a larger number of classes, it is a separate concern. We are working on it, but feel free to create a separate forum thread to discuss it, to avoid mixing topics.
1 Like
Was this resolved for you with 1.9.8 beta.
It is still the same for me but I due to excess workload I had not time to test beyond one staging site.
I will make more staging sites and test during Easter holidays but I am experiencing exactly what you have in your videos. Duplicating elements is so slow its killing me but it is not in the structure panel only. It happens with Bricksforge panel too in quite big GSAP timeline, in ATâs Grid builder (using quite a lot of JS)âŠCustom CSS box (AT Superpower or not)âŠâsomethingâ JS is calling âhomeâ and the reply takes forever.
@Charaf I read your comments in the mail and will get back to you after testing again in other staging sites but not using any of the most popular plugins in Bricks Ecosystem is not an optionâŠThe plugins I use are what makes Bricks Ecosystem what it is save for the âRead moreâ expander element which is irellevant and not causing any issues at all. I donât have much time for testing and itâs costing me but will do.
I am under the impression that these lags were not there or not so obvious in older versions. I will test a staging site other than the one youâve seen with 1.9.6.1 too.
EDIT: I think this message maybe should be moved to the âLarge number of classesâ thread too? I donât knowâŠI posted here but most probably the renaming lag is still present because of the classes number.
1 Like
Yes please letâs move this conversation to the new thread. This thread resolved an issue with renaming elements on pages with a large number of elements. The lags youâre seeing on your site are different as theyâre affected by other factors which can slow down all functionality:
Hi guys! I still experience serious renaming lag in the structure panel on what bricksâs team would probably consider as complex layout â because itâs a medium long landing page. This issue is definitely not solved. It is a bit better when disabling ACSS 
So should I just stop using ACSS?
1 Like
hi, so its solved and not solved? would love to know. thanks for any insights.
Hi @jiripaulas,
Thank you for reaching out and letting us know that youâre still experiencing issues despite the recent improvement.
Could you please try disabling all other plugins and then compare the behavior with ACSS enabled versus disabled on the same page/template? Additionally, if you could share a screen recording of the issue, that would be extremely helpful. Alternatively, you could provide temporary admin access to help@bricksbuilder.io, and we can take a closer look.
In general, for complex & large layouts, we recommend dividing the pages into separate section templates and then importing them using the âTemplateâ element. This approach not only improves performance within the builder due to fewer elements being computed at once, but it also makes managing the page and the site as a whole more maintainable. Could you let us know if dividing your page into section templates is an option for you?
1 Like