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 myapp.com”… “waiting for dhtiece9044.ep.cloudfront.net…” 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? )
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?