Basic Performance Issue: Professional Plan(s), Reserved Capacity, and Time-to-First-Anything-Throttling

This post is going to be a bit on the long side. I’m describing something here that many have observed about capacity in general, reserved capacity, and peak capacity – and how those affect performance of a Bubble site as one makes the journey from Hobby > Personal > Professional type plans.

The app I’ve recently deployed was developed on the Personal plan. And performance felt pretty great – at least in terms of initial page loads, etc. I could see that, at various times, my app would get throttled when there was a lot going on. But I rarely observed painful slowness in terms of just getting to the “first paint” in the browser. And I rarely observed status bar messages like “waiting for”… “waiting for…” etc.

That last one, BTW, if just the basic stuff (like jQuery, etc. that Bubble loads for any Bubble page) - pictured below:

But on Personal, as I got my first Live-mode users, got more traffic, and acquired a few paying users, I did see in the Logs page that that I had a good number of short periods where I was maxing capacity. And as these increased it seemed obvious that it was time to move to Professional and get reserved capacity.

And testing with “Boost” seemed to confirm that, yes, this would be a good move at that time.

So I move to Personal with the default 2 units of “reserved capacity” and see that, indeed, times where the app reaches peak capacity are much less frequent. And mostly things seem faster.

But then as I get more experience of seeing my app perform in this mode – as I’m working on new features and test, etc. – I start to observe something (that to me at least) is new. There are times when page loading (even just my static index page) is sluggish. Very sluggish.

Page load times are very long during these periods. I see lots of “waiting for dhtiece9044…” in the status bar. But during those periods, CPU usage isn’t abnormal and I don’t see Capacity being maxed out.

So I start to wonder, “What is going on? What did I add or do to my site to cause this file to become very large?” (Under the assumption that something I have done in the development of my site has caused overall growth in the assets that Bubble requires to even start rendering the page.)

And I look at lots and lots of things to ensure I’ve got things optimized as well as possible. I make various improvements (that are mostly to do with things that happen in the page, as there’s not a whole lot else on the backend that I can optimize further. Also, I’m not maxing capacity with any regularity, and those server-side processes are performing just fine for me anyway.)

But still the problem of what would seem to be the web server component sometimes appears (and AFAICT, I can’t predict when it will happen). It’s not that the files being delivered by Bubble have grown at all. It’s just that my app’s web server component just can’t/won’t keep up with requests.

Further, what seems to be going on is NOT that the bandwidth between the browser and my app’s server is throttled, but that there are at times a very long pause between the browser’s request for the initial Bubble components and when Bubble actually is able to serve them to the browser. And this delay is sometimes a few seconds.

But again it comes and goes at seemingly random times.

So last night I experimented with Boost on Professional for the first time: Adding 5 units of capacity for the free hour period – at a time when the random slowness is happening. After Boosting, I see that my pages are now loading sprightly once again. There’s no huge delay between the request to load the page and the components being served up to me.

And now I’m pretty bummed out.

Because this seems to confirm that, when you get reserved capacity on Professional, you also LOSE the extra “peak capacity” that one reaps the benefits of on Hobby and Personal apps. (At least, this is what it seems like and that’s my theory for what’s going on.)

I have 2 units and only ever 2 units. While those capacity units seem to be sufficient for searches and API Workflows and other server-side stuff, it’s apparently NOT enough units to ensure my web server component won’t (at times) act like it’s running on an Apple ][ connect to the Interweb over a dial-up modem.

It seems I don’t have any “peak” or “burst” capacity (which must be the case on Hobby/Personal plans.)

Point being: I can optimize the heck out of back-end operations and in-page operations, BUT when the server response time is horrible, page load is going to be just horrible and the time to when we can start to do anything in the page is just horrible as well. (As there are these periods where a long pause happens before Bubble core scripts are delivered.)

But then I add what would be $100/month in capacity and that problem (for the moment) seems to go away.

But geez: $100 buys a LOT of web server capability these days. And further frustrating matters, I’m loading all sorts of stuff from cdns (libraries that are an order of magnitude+ larger than Bubble’s core stuff) and that all works swimmingly… when we can actually get to the point in the page where that stuff loads… and of course all of that is “free”.

I guess my core question for @Bubble is this: Is my analysis above correct? Other folks here have observed the same things and made similar assumptions about what is going on, but I’ve not seen this confirmed by folks on the Bubble side.

It seems really hard to figure out the answer to “what total capacity do I need to avoid this problem?” Like I said, it seems to go away at +5 units (7 units capacity total) but then I wonder how long that might last. And again, adding this capacity would seem to only be necessary to ensure that I don’t hit initial page load problems at random times.

Most of the time, that capacity is just going to be sitting there, unused. (I guess I could then write a bunch of sloppy server-side stuff? :stuck_out_tongue:)

Anyway, the value proposition seems weird. It seems like very soon I’m going to have to add a bunch of units just to ensure that my static “sell” type pages give the type of experience that is expected today.

(And we see other Bubblers suggesting quite often that one’s static pages perhaps SHOULD be served on a free or low-cost service that doesn’t throttle in the way that Bubble seems to on Professional plans. But that’s really crummy, right?

Other workarounds seem to be things like Cloudflare which of course could cache the entire response from my non-dynamic pages and serve it up in a cdn-like way. But the vast majority of my app pages are actually working, dynamic pages that reap no benefit from such a thing – and in fact need to NOT be cached in such a way to ensure that they work correctly.)

The picture I’m getting is that, on plans with reserved capacity, you basically have a virtual machine that is EVERYTHING – web server, database, etc. etc. And the amount of “capacity” really represents the amount of system resources the (hypervisor? scheduler? something…) will ever allocate to my virtual machine. I don’t get any bursting and there’s no granularity in terms of what I can buy.

(In a build-it-yourself system, I’d be saying: “Oh hai, my “app” is just fine, but I need to move this thing to a more reliable/faster hosting platform as its basic server stuff that’s throttling me out sometimes.”)

The thing that seems weird is that this sort of problem just doesn’t seem to strike Hobby and Personal plan apps. The web serving part just doesn’t seem to choke in the same way as a reserved capacity plan will. (They get to burst is one way to put it.)

I realize that all of the above is kind of a whine about the way Bubble works. While it’s understandable, it still feels odd that, as one moves up tiers, you seem to hit this new problem that at times is WAY worse than “my RG loads kind of slow”. Because poor web server component performance means that the time-to-first paint on the page becomes crummy and you just know that visitors are abandoning your site.

(Another way of expressing this: One sort of assumes that the web server component would always be nice and fast and responsive. That one’s pages would be allowed to load nice and quick and that we’d at least be able to show the user non-blocking things with a consistent level of performance. Once loaded, we might experience slowness in terms of rendering dynamic data or showing the user the results of back-end computations or whatever.

But, in fact, it seems we can get into situations where all of that backend stuff is actually OK for one’s app, but that one doesn’t have enough capacity to deliver a good front-end experience. This is just not the way one is used to seeing things work and so it’s puzzling when you first run across it.

Further, the solution seems to be, “I have to pay WHAT for my web server part of things??? Oy gevalt!”)

“Grumble,” I guess?


I’m quite curious in this myself. It’s been something I’ve suspected in the past, but was never sure about. None of my apps get enough usage to run into the issue (and I still have some on the old legacy plan because I’m stubborn.)

I’ll follow along to see if your assumptions are correct.


The weird thing, @andrewgassen, is that I don’t believe MY app gets enough usage to run into that issue either… and yet it happens.

There ARE other potential explanations. Is there a bug here that I’ve tickled somehow? Is my server busted a bit somehow? Possible I suppose.

But I’ve got the very strong feeling that the web server is just completely bundled into the (assumed-to-exist) virtual environment in which app runs and that, for some reason, the web server gets really slow…

Maybe other things get really slow, but if they do they don’t slow down enough for me to mind/notice. (And none of those is as critical as server response time for web visitors.)

1 Like

@keith interesting observations but we would need to validate it in a test app if you could share before moving on to a 2 part solution:

  1. our devs include your use cases as part of their performance improvement initiatives
  2. the forum & support crowdsources a performance-centric app and query design cheat sheet :slight_smile:

@keith, I think, and this is only anecdotal, the way they calculate capacity takes into account the whole stack (web, app, db). So, if you’re using too much compute at the db, then your web server will be affected also.

1 Like

Hi @neerja,

I could certainly provide a copy of my app as it exists today, I suppose. But note that of course the behavior I’m describing really only happens with apps that are in production/in use and are consuming Bubble resources.

As far as what happens with my particular app (this is the GRUPZ app that I’ve shared with you terrific support folks in the past when I’ve had bug reports), the Logs tab from today is a pretty good illustration:

What we’re looking at here is the past 24 hours on a Professional app with default 2 units of capacity. While there are no periods where the app seems to have reached max capacity, there is of course the “your app could have been x minutes faster” note.

And in my specific case, it’s suggesting that it could have been a total of 70+ minutes faster over that period with more capacity. (How much more capacity I’d need to add remains a bit of a mystery.)

Looking at the server capacity usage chart for the period from early this morning to about now, we see Web Requests represent the bulk of used capacity (the green segment is Scheduled Workflows at 10.1% of used capacity):

Drilling into web requests we see Page Load at 5.1%:

Fetching data at 21%:

The pink segment is “Other” at 65%.

Looking at Page load metrics (last 60 minutes as that chart shows) we see:

I’m not really sure what to make of all this, but in short, my app goes through short (and unpredictable) periods where web server response is slow. (The most noticeable feature of this being that one can observe an obvious delay where the browser is waiting for the response from Bubble to fetch Bubble’s initial page load scripts and stuff.)

And, as you can sort of see from the shots above, the number of pageviews in the past 24 hours isn’t enormous. Looking at Google Analytics data for Nov 18 - 19 just now, I see:

Of course, pageviews aren’t the only HTTP activity going on (we’re consuming data from external API’s and such).

This morning as I’ve been working with this app, page loads / page navigation has mostly been quick, with occasional times when I see “waiting for dhtiece9044…”.

Basically, the web server response is “lumpy” :slight_smile:

Hi @Kfawcett: Meant to thank you for this earlier.

Yes, this is a nice short way to sum up what I’ve observed.

It’s just one of those things that’s very odd feeling as I certainly didn’t observe laggy web server performance until I moved to a reserved capacity plan.

@keith @Kfawcett @andrewgassen
if bubble calculates capacity by taking into account the whole stack
would it help if we use a external database ?
what are your suggestions on using external database, because bubble’s DB is very expensive as compared to others like amazon or google spanner etc.

If you have the capability (mad skillz) of using an external database, what are you doing here, exactly? Go build your app in JS with Firebase already.

@keith :joy: no i do not have such mad skillz
I do not know how to code, i was thinking of connecting to external database by the sql database connector plugin
Would it help ?

1 Like

I’m also curious whether or not an external sql db via plugin would help performance.