Editor is Too Slow When Using Many Elements – How to Improve Performance?

I’m building an application that uses a large number of elements.
Currently, I’m facing an issue where the editor becomes very slow and difficult to work with.

How can I solve this problem?

Here are a couple of ideas I’ve considered:

  1. Splitting content across multiple pages to reduce the number of elements on a single page
  2. Using reusable elements wherever possible

Do you have any other suggestions or best practices?

Every now and then turning this off releases some pressure

1 Like

This…

On a single page app, all pages must be in different reusable elements…

3 Likes

use a lot of reuseable elements
use a browser that manages cache actively (arc or mozilla dev)
use multiple tabs - yes I know it’s against “official recommendations” but whilst I wait for 1 tab to load I can jump over to the other tab and keep working (usually separate page/reuseable anyway so low save overwrite risk issues)

multi tabs are also great for when doing bulk database changes and searches because I can let that run for a minute whilst I keep going in another tab (searches can take several minutes to fully process)

working in 1 tab I’ve found slows down my work a good 2-3x because it forces me to wait for bubble editor a lot more

2 Likes

Oh, (duh! moment for me) that way the editor doesn’t load all those items inside the reusables…

Nice, I never thought of that.

I’ve heard people mention wrapping things in reusables previously, hadn’t thought to do entire pages, will definitely be implementing this!

NQU Secure /dashboard page elements tree

1 Like

Huge, will also make it a lot easier to tactically snipe errors in buried groups or elements. I’m hoping I can just use the convert to reusable function to quite quickly switch this up in my editor.

1 Like

just be VERY mindful of using workflows such as “on page load” and “if when” and “do every” when you have reuseables…

you can easily stack unintentionally and end up with 20 workflows running on page load if you don’t add conditions (only run when visible etc)

4 Likes

I’m not convinced there’s any difference between using reusables and regular groups if you have a SPA and everything is set to only be visible conditionally. I know those hidden groups aren’t loaded in by default because when you toggle visibility there’s a “hitch” for a split second before it pops in.

Also just throwing this out there, adding &issues_off=true to your editor URL will disable the checker entirely and can speed up things, but your also working without error checking so be mindful to remove it and check for errors after working.

1 Like

Thanks for the browser recommendations

Maybe I’m misunderstanding you…

but I have an SPA with about 50 or so reusables.

Having reusables makes it much faster to edit each group instead of having a page that goes on for a half a mile?

1 Like

My page is completely blank when I open the editor.

There are container groups for each “page,” equivalent to your reusable. These are collapsed by default.

I get to easily reference other components by collapsing/expanding rather than having to go to a separate page/view.

this works fine in simple apps but as your app gets more complex you’ll definitely want to lean into using reuseables

basically on editor load it loads all the editable elements but for reuseables it only loads a preview of it so it greatly reduces the load in the editor

it’s also very useful to compartment workflows so that your on page workflows are manageable
and also as you scale you don’t want to create the same table for “contacts” 10 times throughout the app

I am disputing this claim, at least for elements which are hidden by default and only show upon a conditional.

What folders are for.

I use reusables for popups and workflows which need to be shared across pages.

everyone uses bubble differently but I find reuseables one of the best ways to improve editor performance and app organization

I focus on building as much as I can modular so that when I need to build something new I literally have 60-80% of the parts ready to go and can just assemble it in a new way - this speeds up dev considerably and also keeps the whole app consistent across pages and functions

I generally break down reuseables into component parts - for example:
search pop reuseable contains
contact card reuseable
keyword search reuseable
filter reuseable
select/deselect reuseable (counts selected and toggles yes/no so the pop list can toggle to show selected only)
contact pop - to edit a row

contact pop contains
archive icon - has confirm focus and returns a value to trigger the workflow outside of it
tab reuseable - I have several of these for handling different data types - text, date etc
table reuseables
history reuseable

reuseables are incredibly useful and powerful in bubble - I’d definitely preference them over folders and everything on one page wherever possible.

then pair that with nesting workflows within reuseables (trigger custom event from within reuseable) and you have a very uniform, clean and structured app that is a lot easier to build and maintain.

3 Likes

We’ve found that this practice is one of the biggest indicators of technical debt when clients come to us with apps to work on. It’s a really bad developer experience having so much happening on one page and makes bugs more likely.

Agreed.

Depends on your app. For me reusables breaks everything into silos and this gets in the way of visualizing how things work together. I find them claustrophobic when used as “pages.” Slows me down. Managing custom states and properties can also be a pain.

Using Bubble is the biggest indicator of technical debt.

These “things happening on the page,” are they with us in the room right now? You can see as much or as little as you need to if you are nesting things correctly and have visibility conditions. My editor runs flawlessly except for the slight hitch upon first load and when I click the visibility icon for a “page” container (which would be expected).

1 Like

When logic is separated into reusable elements, it’s virtually impossible for logic to interfere with each other. That’s the benefit of reusable elements.

And keep in mind I never said that this practice alone is awful (though I think you’re making life hard for yourself)… just that if the developer does that, it’s also likely they do other silly things that reduce the likelihood we can pick it up.