When adding a lot of elements to a page for a very long page the editor crawls to halt in Firefox (marginally less so in FFDev it feels like). Each letter typed takes what feel like one second.
This is a LOT better in Brave / chromium - even though those browsers don’t handle resource management as well (RAM) with multiple tabs open. Below are two videos: FF 104.2 & Brave [
Version 1.43.89 Chromium: 105.0.5195.102 (Official Build) (arm64)
Can you provide me with such an extensive template as json? I just inserted 5 community templates (which is a lot elements), but can’t feel any laggyness.
Is there anything else I need to be aware of to “provoke” the problem? Does it occur in every Firefox version, or only the current one?
yes, I can (see attached). So I have a mix of classes, some javascript etc on this page (took me a while to figure out that I can only export templates.
I think to provoke the problem, lots of classes might be helpful. Since that would require to lad those as well. I have used the community templates as well, but I prefer utility classes. This version is built upon ACSS, but I have had problems with my own cobbled-together set (although in a much earlier version).
Yes, it occurs in FF and FF Dev (different versions), and I can see it in Chrome/Brave, but it’s barely noticeable. There is a very slight lag even there.
@timmse K, just noticed that this also occurs (but not as slow) when using var() in fields (margins/colors/padding). I have set up some color variables and other things. On a different page, editing with Brave (latest) and only two sections with less than two handfuls of elements, I saw this behavior when I used a variable in the same element or in another. So maybe it relates to HOW the CSS is pulled in?
I can’t quite provide reliable steps to reproduce. It seems like with growing complexity of a build, the builder tends to slow down, though I never experienced it as badly as shown in the OP’s video.
I had the issue when building a 2-column section with nestable accordions in both columns. Both accordions had styling applied to them. The builder was quick and responsive before adding the accordions and slowed down noticeably after they were placed.
First encountered the issue on projact.2sinn.it and found I was able to reproduce it on bricks.2sinn.it. However, later in the same day, the builder went back to normal speed even with the accordions present.
Tried both in regular (with a bunch of extensions) and incognito windows. Same result. I have the following plugins installed on my builds:
All in One WP Security
All in One WP Migration
All in One WP Migration FTP Extension
Complianz
Favicon by RealFaviconGenerator
Rank Math
Search & Replace
WP-Optimize
What if the number of revisions and all the data associated with it that is still saved somewhere is causing the lag?
But I have to admit that on several occasions when logging back in, recent changes were gone. So I have to manually apply the last revision to bring it all back.
I think its just as the page gets longer, more elements and variables used, etc. My home page is really slow taking at least a half second to type each text letter.
But if I edit my header or footer templates things move very fast.
Similar experience here, one page where I have 6 query loops, with 6 dynamic light boxes from Oxy Extras, and some more sections, creates lag shortly after refreshing the builder. I have hard that can have something to do with ACSS and how classes are handled on the database. Have you been using ACSS?
Right now, for me, Bricks in general has been more laggier than Oxygen. I know not everybody experiences it, but I have tried in two hostings, local environment, most browsers and in general has been laggy for me.
Hopefully they will be able to tune things to have a faster experience
