This is part rant and part education for you all.
I have been on the bubble platform for 5 years now and have a dedicated server and also many community applications.
I have delved deep into the timings and stats of backend calls and validated my findings with support.
they are not batching enough of their calls from the client and many are sequential when they could be parallel. Without batching, we are at the mercy of number of browser connections.
CloudFlare is masking a huge issue which if fixed would improve performance by 5x. The connection from Bubble to CloudFlare (cloudflare to you is cached) is not caching the SSL connection (validated by support), so EVERY SINGLE CALL is adding 100-150 MS. Mgets, bulk_watch and search should be 50/70 ms and are > 150ms every single time. This issue + #1 makes for a very slow application. The fix is very easy for them do, and 2 years ago i just gave up fighting with them to get it done. crazy.
in addition they hadnât enabled gzip compression from the bubble servers last i checked, which is also masked by cloudflare but not as big an issue.
agreed. but the impact across all clients would make it worthwhile.
I understand cloudflare for libraries and images, but data calls should go direct also with the fixed ssl caching.
Does anyone know if these types of features is a priority for them?
Seems to be they are focusing a lot on entry-level features (think âcomponentsâ or âelement opacityâ) vs. actually improving performance and features for expert bubblers.
This is really not good news - I have been on Bubble for only 6 months+ and starting to feel performance being a constraint. I am only on Personal Plan right now so I was maybe hoping for increased performance with the higher pricing products.
If performance is not decent most of the time - the product is more or less useless in practice.
They are talking about their heavy large scale apps on a dedicated plan and need to squeeze every ounce of performance.
If youâre on a personal plan and feel like your appâs performance isnât great then just upgrade and see how it performs then. Though i would recommend you work to optimize your Bubble app first.
Most beginners in Bubble tend to overreact here in the forums when they should be learning how to optimize their apps. I have a complex ERP for my organization running on a personal plan and have no performance issues. Any issues that once were slow I just learned how to optimize better.
Youâre right for most people. I think the problem is that since they are beginners, they envision their app will grow to that point one day (and I hope that it does!). And so when investing money and a lot of time of learning and learning and then developing they want to feel confident that theyâre not doing it for nothing and that one day their app will be successful and it wonât be too much work to get it performing right.
I realise that - and I am also humble that I have to learn more. But you kind of want to know for sure that the problem is my knowledge rather than a limit to Bubble performance.
At the end of the day, it doesnât matter how fast your product is, it matters if itâs answering a need for your client. I used to spend tons of time focused on speed, squeezing every millisecond out that I possibly could, re-working pages, going from a multi-page app to a single page app and do you know how many people were complaining about speed? 0.
Iâve wasted a lot of time focusing on making things faster when in reality, nobody thought it was slow to begin with. When I would do trainings with my clients, I would always ask how the speed was and after hearing âThe speed seems fineâ so many times I decided to stop worrying about it.
Before Bubble, I worked on a very old codebase that is still used by lots of state park facilities to this day, which is miles slower than my app in comparison, but we rarely had complaints about speed because at the end of the day it was a tool, and it was a tool that got the job done.
Now, Iâm obviously not saying this applies to everyone and you should use the best practices you possibly can to make your app efficient, but from my point of view when it comes to Bubble and Speed, I have not had any issues or complaints in that regards and Iâm going on year 3 of being live with Bubble.
I have broken Bubbleâs data handling even on expensive plans. It simply doesnât work consistently as the OP said. And I can 100% prove it doesnât work.
There are workarounds of course. But that is not âoptimisingâ.
Sorry if i sound accusatory. Not trying to assume anything about how your app works.
Iâve been stalking the forum daily since i was in my Bubble jammies and made those beginner boo-boos myself. Just pointing out what my experiences reading the threads by Bubble beginners.
Thereâs very clear division of Bubble users based on my observations. Bubblers with little to no coding background, those with and then those with loads of experience like @NigelG and OP
Depending on who you are talking to, you can get very different responses about what is âoptimizedâ. Whatâs important to know is that one Bubble has itâs own layer that we have no control over but you can always optimize your Bubble apps. Sometimes with native Bubble and sometimes with workarounds.
Optimization using workarounds is just the nature of the beast for products like Bubble.
I think only a small percentage of performance complaints are valid around here. I used to do a lot of coaching and could constantly improve performance/speed by fixing obvious things.
Our main app is a mix of bubble data and external JSON api calls and yes is complex, but even pages that are not very complex suffer from the loading performance hit that i mentioned.
I have another app that hosts landing pages for campaigns and it was taking 4-7 seconds to load, that just wasnât going to cut it. So I have moved the landing page to Azure Razor app and it loads in under 1 second, while i keep the admin and complex app within bubble. You can try it. goto https://oneseed.green and then click the oneseed campaign on the middle right side. That landing page is bubble data being rendered from azure app insteadâŚ
but to bring this back around to the original point.
There are of course best practices on how to improve performance of your app, both perceived and actual.
I just want the bubble architecture to not be the bottleneck on complex apps and it doesnât need to be.
Even that times out at large enough numbers. What you need to do is batch up the deletes into packets of 100 or so and maintain a pointer (tend to use created date) for where you are in the list.
You canât rely on a search working correctly, as Bubbleâs âIndexâ to your data is deleted differently to your actual data. So if you delete 100 and then say âhey, get the next 100â thinking the 100 will be delete - it will still have some of the 100 lurking about.
So you save the âcreated dateâ of the 100th - and then use that in your recursive workflow to pass into itself and the search can start from that created date.
Still takes far far too long.
It used to be that you could copy the empty table from Live (assuming you hadnât gone live yet) and it would work really quickly. But Bubble stopped that recently.
Alternatives are running Data API calls. Or, as I did recently, just setting up a new table and binning the old one
I can attest to this - and why I migrated my backend away from Bubble (and now migrating frontend away as well).
Every month, I have a massive CRON job which needs to update all users. Issue is, I have users in the 6 digits, and every month, I get complains that somebody was missed out in the update somehow.
When I raise this to Bubble, somehow itâs always my fault, my logic is wrong. But ever since I migrated to Xano, Iâve not had that complain, not once. Clearly my logic is right
