BUBBLE Editor is too slow. Is it because of the specs of my computer?

Same! Editor has been slow. At times it becomes difficult to do anything in it, taking over 45 seconds to load actions.

1 Like

When this happens on my mac, I check the activity monitor. Usually I’ll see many instances of “google chrome (renderer)”

I force close the main instance of chrome, the renderer instances close by default. Then it runs again smoothly when I return to bubble.

2 Likes

A lot of times that will fix it but still have issues. Today i watched my database load that only had 100 entries in a datatype take over 5 minutes to load with any values. Grrrrr

1 Like

Hey @yuta :wave:

Your Mac is getting up there in age. I think it’s about 8 years old. An upgrade can help for sure. I have 32 GBs of ram on a Mac that I bought last year and it is super fast. I do wish we could run Bubble on the slower computers though. It doesn’t make sense that it doesn’t run well.

Hi @jared.gibb

I’ll try this today. Thanks for the tip. I generally have about 4 bubble tabs open when I’m building.

Are you creating all the functionality for the different ‘components’ on that single page?

I’m sure you have groups that are visible or not at different times depending on how the user is navigating and inside of those groups there are specific feature sets…my question is whether or not you are creating all the elements and the workflows for each group on that same single page in your editor.

If you are, that is the reason for the slow editor.

To get around this, instead of creating each feature set on the same page, I create the individual feature sets in a reusable element and then I place the reusable elements into groups on the page.

This means my editor doesn’t slow down as I build separate features in their own reusable element and when the feature is all finished and tested, I place it into a group on the page. Eventually the editor will be slow when I have added a lot of reusable elements on the same page, but only when I am loading that one page and since the only thing I’m doing there is adding the navigation workflows, it is not much of an issue overall.

Learn More

Boston85719 is an expert Bubbler with a decade experience as an educator. Real name Matthew, he has been actively building SaaS apps, marketplace apps, scheduling apps and more for clients, himself and for sale as templates.

As an official Bubble Bootcamp Instructor, he leads Bubble Bootcamps on a regular basis.

Always willing to offer advice via the Bubble Forum, Matthew also offers Private Personal and Group Training Sessions.

Through his site, NoCodeTrainer, Matthew provides a range of tutorials with editor access to help you jumpstart your Bubble development.

Always accessible you can send Matthew a private message via the forum or send an email directly with your requests.

Be sure to checkout the Stripe Integration Course when you are ready to integrate Stripe payments to start monetizing your application via product sales or subscriptions.

Stripe Integration Course

NoCodeTrainer.com

3 Likes

wow.
Thanks for the good information.

For those who are trying to make a large-scale application from now on,
we don’t recommend mac book pro or iMac which is under 8GBs of ram.
It’s too late, stress builds up, and work doesn’t go on

i will buy iMac which is over 32GBs of ram.
I do wish we could run Bubble on the slower computers though too.

thanks.

1 Like

I can understand what you are saying.
But isn’t that difficult?

because, all the functionality are not the same design and layout.

so, i think ,
it is normal that my app has the different ‘components’

wow nice. Thanks a lot for updating about your app.

For me personally it is not difficult. It is the same as making a multipage app where all functionality is on that page, but in this approach it is in a reusable element.

I do believe you are correct to assume that it is ‘normal’ in the sense that a lot of people might take that approach and fall victim to the pitfalls of a slower editor.

For me, in my experience, it is a better approach to use the reusable element method.

so, you mean,
your app’s all components are the same design and layout ???

Design as in styles and look, yes to maintain that necessary consistency for design across the entire application.

Layout as in size of elements and such? No, because I can create a reusable element that is originally 300px wide and put in the responsive settings so that if it is stretched it will look good and function properly, and if I want to place that reusable element directly on the page and stretch it by altering the size I can and have responsive still look good.

Same idea, I can make it 1200px to start and have proper responsive settings and make it so that it when width is decreased still look good and then drop it on the page and set the width lower than 1200px and it will still look good.

Check out this video demonstrating

Youtube Video Response

1 Like

Isn’t that a method that only works for pages with a simple design?

I don’t think your method is available for pages with complex designs and pages with complex content.

What @boston85719 described with reusable element single page apps is in my opinion by far the absolute best way to build bubble apps. It’s actually exciting seeing someone else using this strategy instead of traditional single page builds.

Personally it’s faster on my editor, allows me to optimize easier, reduces my time It takes to build and search for workflows, is way cleaner, and maintains lightning fast load speeds when done right.

If you’re going this route my biggest recommendation is to reduce custom states used like you’d traditionally build and start to utilize paths/parameters and reading URLs then saving to state similar to how apps like Facebook does.

You’ll save yourself a ton of time trying to pass data.

This route also does really require an understanding of satellite data types and database relation but is very much worth it.

sorry.
I couldn’t understand what you were saying
now, i got it what you mean.

if i have 3 contents.
make these contents as a reusable element.
then, put these together on one page

is it correct??

No, it will work for any design if you know how to use the responsive editor properly.

It is.

Each feature set is a reusable element. Then place that onto the page. If you have 30 feature sets, they each have a reusable element so there will be 30 reusable elements. Feature sets are things like the messaging system, the ability to create blog posts, create schedules etc.

First time I had my editor slow to an unusable speed had to come up with something and this is the only way to do it.

Also is great for being able to have ‘plug n play’ type functionality when building.

Absolutely. I rarely make use of custom states…getting to this point helps with some complex functions like a notification system that when the notification is clicked you can be navigated to the exact place in the app of relevance.

1 Like

I’ve switched to using Brave as a dedicated Bubble browser and Chrome for my testing.

1 Like

Can you talk more about this idea

@toby2 any specfic reason why you’ve went to brave for testing?

@jared.gibb For sure, it depends on app setup but for an example case i have a very large heavy feature CRM app with a drag and drop proposal builder as one of the features. To keep load speeds high we split the data to ensure as little data is being loaded as needed.

The data looks like this:

Data type : Draft Proposals
Fields: Name, description, user(obj)

Data Type: Draft Proposal Content
Fields: user(obj), linked proposal(obj), HTML, JSON

Data type : Sent Proposals
Fields: Name, description, user(obj)

Data Type: Sent Proposal Content
Fields: user(obj), linked proposal(obj), HTML, JSON

Data type : Sent Proposal signers
Fields: Name, email, phone, linked sent proposal(obj), trackID, user(obj), viewed time (list of dates)

Data type : Finalized Proposals
Fields: Name, description, user(obj), finalized date

Data Type: Finalized Proposal Content
Fields: user(obj), linked proposal(obj), HTML, JSON

Data Type: Finalized Proposal Signers
Fields: Name, email, phone, linked finalized proposal(obj), user(obj), signed time (list of dates)

Data Type: All Proposals
Fields: Finalized, proposal signers(obj), Finalized Proposal Content(obj), Finalized Proposals (obj), Sent Proposal signers (obj), Sent Proposal Content (obj), Sent Proposals (obj), draft proposals (obj), Draft Proposal Content (obj), user(obj)

It’s broken up like this to ensure load speed at scale so unused large data objects aren’t being loaded unless actually needed. Honestly, it’s quite obnoxious to build like this but it helps load speed a ton.

How is this structured?
In our single page app our page that displays the list of proposals it uses a do search for draft proposals ONLY when proposal selected status is draft. If filter is sent it will search sent, and finalized will search for finalized. Once a proposal goes to the next status it’s removed from the prior so searches stay small and light weight.

When navigating to the view or edit page it will load the “Draft/sent/finalized proposal content” as well but our initial dash page doesn’t need to load it because as you can imagine loading 10k records with a large amount of HTML/JSON can be a heavy load thus making the search time incredibly slow and now scaleable. Same concept with signers.

In the case we need more flexibility or the user intends to search ALL (not default) we use the satellite field “all proposals” this is usually unlikely but there if it’s needed but it’ll definitely be a heavy load.

This helps with save display speeds too, if your list of proposals to the users only saves a few light weight text items it’ll be near instant even if saving some 10+ items with workflow api for any reason.

If it wasn’t done like this rather if your data was structured as something like below -

Data Type: Proposal
Fields: Name, description, user(obj), finalized date, HTML, JSON, Signer Name, Signer email, signer phone, signed time, views, Status (option set).

Or any variation of the above you’re expecting bubble to load pretty heavy data even if just displaying a simple list of proposals name in a repeating group you as it needs to load the full record including the heavy content like HTML/JSON and you’ll hold per say 10k items in this DB type rather than just a fraction when splitting up the data to be more light weight and loading required data dependent on use case like the first data structure.