Editor high memory usage - 14.2 GB (new personal best)

Need help
1

I just opened my laptop for the morning coffee :coffee: to this little beauty.

CleanShot 2026-01-08 at 06.34.01@2x
CleanShot 2026-01-08 at 06.34.01@2x473×312 14.4 KB

I’m no stranger to 4 - 5 GB usage, but this is odd. Most of the times when it reaches 4 GB the editor starts weirding out and then crashes.

Any one else experiencing things like this? You guys got some solutions?

I’ve tried lots of stuff and nothing helps. This is on Brave with “run checks on backend workflows” on, but I’ve tried:

  • on all the browsers: Chrome, a ton of Chromium-based browsers, Firefox, Safari, hell, even Edge.
  • all the shields up of Brave.
  • turning on/off the “run checks on backend workflows”
  • “optimizing application” multiple times
  • constantly deleting reusables – I’ve got a sneaking suspicion there’s something in the app’s JSON that triggers the editor to go into an infinite loop.
2 Likes
2

This usually happens when the editor tries to load a single page or reusable that’s extremely complex. The editor isn’t crashing, your browser is killing the tab because it’s using too much RAM. Isolate the specific page or element causing the spike and simplify its structure.

What you laptop spec, for auch sute i have a old power house.

MSI i7 9th, with 64GB Ram, and 6GB graphics card.

3

Hey @rico.trevisan Yeah, I’ve seen this happen in big apps. Bubble’s editor can spike memory when there’s a lot of data in reusable elements, groups, or complex workflows. There’s no perfect fix, but splitting the app into smaller pages, reducing deeply nested groups, or temporarily disabling “run checks on backend workflows” usually helps keep the editor stable.

Also, Chrome/Brave can hit memory limits faster than Firefox sometimes, so trying Firefox with minimal extensions can give you a smoother session.

4

How do you measure complexity?

5

Here’s what the Bubble Bot replied – a interesting coherent set of ideas, but I’m not sure it’s a great list of suggestions:

Here are several targeted approaches to help reduce this memory consumption:

Immediate Editor Optimizations:

• Disable the Issue Checker: Add &issues_off=true to your editor URL to reduce memory usage while working

This can’t be a good idea. Can you imagine telling a developer: “turn your compiler off while you work”?

• Disable Beta Changelog Feature: Go to Settings → Versions and turn off this resource-heavy feature

• Limit Editor Instances: Keep only one editor tab open at a time to avoid resource conflicts

Browser-Level Solutions:

• Use Incognito Mode: This helps identify if browser extensions or cached data are interfering with performance

• Clear Browser Cache and Cookies: Access your browser settings to fully clear both cache and cookies, then restart your browser

• Refresh Frequently: Manually refresh the editor regularly to clear accumulated local cache data

If this is a real solution, why not build that in to the Editor?

App Structure Review:

• Use the Optimize Application Button: In Settings → General → App File Management, this shows unused elements you can delete to reduce editor load

Done this a few times. It does clear out a lot of stuff, but it also destroys legitimate stuff.

Given your specific reproduction pattern involving branch switching and overnight sessions, try refreshing the editor after each branch switch

If this is a real solution, why not build that in to the Editor?

and avoid leaving it open overnight.

I believe that is called a memory leak.

1 Like
6

@rico.trevisan just like @connect10 point out there is no simpler way to mesure complexity of a app, but as he pointed

7

Thanks.

I’m not sure if it’s useful, but this is the page that was open overnight.

CleanShot 2026-01-08 at 08.05.22@2x
CleanShot 2026-01-08 at 08.05.22@2x1098×1270 78.3 KB

CleanShot 2026-01-08 at 08.05.39@2x
CleanShot 2026-01-08 at 08.05.39@2x922×966 49.3 KB

  • “run checks on backend workflows” was disabled
  • all beta features were off
  • Brave
  • no extensions
8

Also realized that I had been logged out overnight.

9

Looks like a memory leak to me.

1 Like
10

Also use Brave. When i’m in the editor I only use private windows and disable cache in the network tab, does seem to help a bit

1 Like
11

To me, it also makes sense that this is a memory leak.

There’s no way around it, the more you use the editor there, navigate between different pages and elements, and spend an increasing amount of time in the editor, the RAM usage keeps going up insanely.

Now 14GB, I had never seen that before :joy:.

One thing I always do when I notice that the Bubble Editor is already getting slow or consuming too much memory is simply copy the current URL, close the tab I was on, and open a new one, then everything goes back to normal.

12

Funny you ask, we’ve built this tooling :smiley:

Does this track?

image
image1920×1080 110 KB

About 26% of your app’s elements have unnecessary expressions which is compute intensive and doesn’t actually provide any development value. Your meeting page is a good example of this.

1 Like
13

Damn.

14

Nice tool! What’s the url? What’s a good complexity level to achieve?

That’s the culprit indeed! I’ve been surgically removing tons of little things, but without tests it’s a Jenga tower. I will continue removing stuff.

15

Private internal atm :frowning:

16

How do you measure this? As in how do you define what is necessary or not without having access to the app? Serious question.

I can only view it as “very subjective” so that’s why I’m asking.

17

References like “Parent group’s thing” are unnecessary. It’s generally used to pass data down groups, but any situation where you DO use that, you can also just reference the element directory, avoiding chain of parent group’s X that serves no purpose other than to get data from a superparent to a child, and adds compute intensity to evaluate all of those expressions.

If you have 10,000 elements on a page (or more if you include repeating group children), that adds up.

Parent group’s thing should be treated as an anti-pattern.

Well, you can measure a lot without access to the editor. All pages can be fetched anyway and evaluated client side, because everything on a page/workflow related is identical in front-end as it is in the editor.

4 Likes
18

Is each instance generating and/or running a JS function over and over again?

19

Any expression evaluation incurs complexity (our abstraction which deals approximately with compute)

20

I was just evaluating the pros and cons of this in my head over the last few days as I rushed through a new module that became a lot more complex than I expected.

Good to hear it from someone who works closely with the Bubble team.