A fair and honest chat about Performance

Questions
1

I’d like to ask a question about Bubble’s performance and touch on some of the considerations someone looking to begin building on the platform may have, without drawing the ire of the community. I’ve spent the last several weeks going through as much learning material as I can get my hands on (Gaby, you’re great!) and I think Bubble represents an exciting new frontier in app and web development. Something I can’t help but to notice, however, is the throughline in these boards around performance issues so my hope is that some of the more experienced Bubblers can share their experiences.

There is no doubt that deciding to use Bubble is an investment. Learning how to be proficient building on the platform takes time and requires commitment. Bubble is exciting because it advertises a low barrier to entry for someone to make a dream app into a reality and potentially launch a business. I see several good examples of members here who have started businesses, in some cases by building an app or offering learning/development services.

My concern comes from the notion that I commit to going down the road of building a business or app on Bubble, whatever that may be, and find out later on that the end-user experience is lacking due to unacceptable performance. I’m not talking about just roughing out a “MVP” to show off as a proof of concept, but rather treating Bubble like a serious RAD platform to build a sturdy, reliable and performant product.

To sum this up, I think Bubble is great and fun to use. My goals are to do something more than trivial with it and know that if I am going to invest my time in learning and building a product that someday might get hammered by API calls, database queries, and high volumes of traffic that it will be able to withstand it.

I’ve seen other posts about performance get dismissed out of hand which is unfair. Like any investment (time or otherwise) doing your due dilligence is just apart of the process and asking questions upfront about potentially limiting factors is prudent. So…

  • Is Bubble continuing to invest in this area of the platform? If so, what optimizations can we expect?
  • Is the Bubble team sympathetic to these concerns or have they been belabored to such a degree that the attitude is largely “it is what it is”?
  • Can anyone assuage these concerns or is the bottom line just that using Bubble is a trade-off. What you gain in convenience you lose in performance?
  • Does buying more server capacity adequately address performance woes?
  • Have you found yourself in this situation and was there a solution or did you cut your losses?

And yes, I’ve read the Performance Q&A Guide. This post isn’t meant to find an answer to any specific performance issue but instead to have a more academic discussion on the subject.

34 Likes
2

Performance is one of the top two complaints I see about Bubble (the other being mobile exporting), and many of the criticisms are valid. Many get dismissed, however, because folks go about raising their concerns the wrong way.

Your post is constructed well and comes from a good place, so I’m more inclined to weigh in. The performance of Bubble has never been an issue for me, but I also only scope projects within the boundaries that I think Bubble excels in. I see Bubble as one tool, not as THE tool. Some apps are just not gonna work well with the limitations of the platform, and I’ve come to accept it.

I used to point people to Bubble for anything, but I think that’s a bit of a disservice to both the builders and the Bubble team. Bubble is really solid for CRUD style apps, and since most of my projects fall into that category, I’m fine with it. Others, of course, not so much.

I don’t know how much better a dedicated plan may be. I’d love to see some folks on a dedicated plan weigh in on the matter, since the biggest performance issue is DB loading speed, and I don’t know how much “capacity” actually helps with that.

So, my TL;DR is that Bubble is a fantastic tool for some jobs, but not all jobs. Real limitations, but very real benefits, too.

13 Likes
3

Our goal is for Bubble to be as fast as any comparable hand-built solution, and we’re very aware that in many scenarios we currently are not, so we are definitely sympathetic.

That said, we’ve run out of the majority of low-hanging fruit on the performance front: most potential speed optimizations on our end that we’re aware of require significant engineering efforts. At the moment, we’re investing in hiring and training engineers to build out our software development capacity. While we do this, our ability to tackle big projects is somewhat limited, although we hope that changes over the next few months.

So in practice, if you contact us about a specific performance issue, what you’ll generally get from us is advice on how to change things on your end to optimize your app, which might require making some compromises on your preferred design. (Although, occasionally a user report does identify an easy-to-fix issue we weren’t aware of that we can immediately address. This is the exception rather than the rule, however).

Some of the major things we’re aware of that we plan to address on our end include:

  • The total size of the javascript we send to run an app is high, which can slow page load, especially on slower internet connections and older devices
  • Because of the way we ignore null filters in searches, users often inadvertently request much more data than necessary in order to load the page (we plan to fix this in the short term, since it’s a relatively easy improvement compared to other things on this list)
  • Writing data (creating, modifying, and deleting) is slower and more capacity-intensive than I believe it needs to be: I think there’s significant room to speed this up
  • Likewise, importing large quantities of data can probably be significantly improved
  • Currently, workflows must finish in under 5 minutes, which can make it challenging to do operations that touch large quantities of data in a reliable way. While the “Schedule API workflows on a list” action can sometimes be used to work around this, this action currently requires loading all the data that is to be modified, and then adding a scheduled task for each action in the list, which itself can hit the 5 minute limit
  • Our debugger doesn’t always make it easy to identify what elements of the page load are slow and why

In general, the advice we give for improving performance on the user end:

  • Whenever possible, build small, simple pages. This is often a better user experience for your users, and makes a big performance difference: the total number of elements displayed on the page is a big driver of performance.
  • Think about what data you actually need to load in order to show the page, and just load that data. The largest driver for slow page loads other than total number of elements is total number of data items
  • Avoid modifying data on every page load. Adjusting element states to track where users are on the page performs much better than modifying things in the database. Avoid modifying data in “do every X seconds” events and events that run automatically on page load or sign in.
  • When you need to do a calculation that involves touching a lot of data, if possible, do it behind-the-scenes periodically using a scheduled workflow, then save the result and use it later, rather than doing it every time the user loads the page. For instance, if you want to show a total # of X on your homepage (like, your total number of signed-up users), periodically calculate it via a scheduled workflow, and save it to the database. That way, a homepage load only touches a single data item instead of touching every single user in your database.

These tips can make a big difference: I’ve often investigated a user app with performance problems and discovered that a single poorly-optimized search was driving 95% of the performance issues. Definitely use the capacity usage drill down chart on the logs tab to investigate where capacity is going. And as mentioned above, we plan to add additional tools to make it easier to find slow things that don’t show up in the capacity chart (for instance, seeing on page load which searches are loading the most data).

As far as the decision to upgrade to dedicated goes, the areas in which it helps the most are:

  • Geography. While we may eventually offer shared plans hosted outside the US, this is likely at least a year away. If you’re in a location where hitting the Bubble servers are slow, dedicated can speed this up by moving the servers closer to you. We serve large static assets via AWS’s CDN, which should be fast regardless of geography (with some exceptions such as China), but fetching the page html and doing database queries requires hitting our servers.
  • Operations that modify or read a lot of data. These typically run substantially faster on dedicated (though the above-mentioned improvements will still make a difference for dedicated customers as well). These operations can also often be sped up on share plans via adding more capacity, though dedicated has somewhat less overhead.
  • Stability. The ability to test your app on our main cluster prior to upgrading to the latest Bubble code is very useful for situations where stability is highly important, and while dedicated clusters do go down, they are significantly less likely to be affected by a Bubble-wide outage than shared plans are.
60 Likes
4

Thanks @josh for this helpful response.

Until performance can be improved I think that the work you are planning on workflow consistency guarantees and no timeouts for long operations (from the roadmap) will also do a lot to help.

I have no idea how easy it would be to implement, but an event which was returned when all items from a workflow on a list are completed in conjunction with the above would do a lot to make it easier to manage long and slow operations, so that we can at least ensure and be confident of eventual completeness (even when it is going to take some time to run). Without this, the only workaround I have been able to find is to write run status information to the database, which in itself has performance issues and also seems to easily lead to race conditions.

4 Likes
5

This isn’t easy, because scheduled workflows are independent of each other once they are scheduled.
What we could consider doing in the near term is remove restrictions on recursive API call scheduling, which would let you do things such as “Find the first item that hasn’t been modified yet, schedule a workflow on it”, then have that workflow modify the item, then find the next item that hasn’t been modified yet… and so on, until everything’s been processed. We implemented the recursive restrictions to protect Bubble from an app scheduling an infinite loop of activity, but we did that prior to the capacity system: now that we have the capacity system in place, this restriction protects you from yourself, but I don’t think it is necessary to protect the Bubble systems as a whole.

Would that be a decent short-term band-aid to this issue? I can look into the feasibility of doing this.

17 Likes
6

Can’t thank you enough for this type of response. A large part of why I continue to point people to Bubble is because of the team supporting the platform. Y’all always get a big thumbs up from me, and posts like this are why.

29 Likes
7

I have a bubble app with 300k users, millions of workflow runs a month and ~500gb of data.

image
image802×388 19.2 KB

image
image800×64 4.47 KB

I went through a lot, I’ve experienced 100% database usage
image

600k workflow runs / hour

image

even viral 300k+ page views in a 4 hour period.

image
image732×157 6.38 KB

I would say that I wish I knew some things before committing to bubble.

I pay ~$2500/month for my dedicated server and we are really slow. (especially repeating groups when you have a lot of data and you are doing a search with a constraint, once you have 20k+ entries and your constraint is really complex, performance get’s really bad)

The app is really complex, but bubble can’t seem to keep up with what we are trying to build.

Unfortunately the internal bubble team won’t be giving you any special treatment even when you pay $2,500 a month. You still need to wait 2-5 days for email responses and generally speaking many times unable to help.

Performance issue is real, so real that we are working to build everything we have outside of bubble.
I’ve hired the best bubble minds to help out with performance and we are still unable to solve them.

My suggestion: look at bubble in it’s current stage as a great prototyping tool and if you start receiving traction, build it with code right away.

I think the most valuable thing for me would be if there was a way to hire engineers from the internal bubble team to help solve issues and optimize performance.

With that said, I’m probably the biggest bubble fan - but it needs to evolve and solve performance in order for us to look at it as a viable and scalable long-term solution. For now, it’s an amazing prototyping and market research/testing tool.

Based on my experience, I would agree with that statement.
What you gain in convenience you lose in performance.

37 Likes
8

I would say that if @josh and @emmanuel can address the issues you are having, and either applying the fixes to every app on the platform or sharing the design issues that led to your low performance then it would give a lot of users comfort!! I think many of not all of us dream of having your numbers though!!

6 Likes
9

We did that with Josh in some cases and I think they applied some findings to all apps, but recently they seem to be busier than before.

1 Like
10

Thanks for sharing your apps details @feee. You mentioned that your app is complex and performance is a real issue. I was wondering do you feel this has a restriction on growth of your business and app and do you receive complaints from customers, if so how do you deal with them.

a fantastic question from @mason thanks very much.

3 Likes
11

The recursion problem, if it can be addressed, would go a long way with me. I want to be a good citizen and avoid causing infinite loops, but I do need to run APIs on some fairly short lists – 2 to 10 things, with another recursive loop for 2 to 3 things each. This doesn’t seem like a lot. I would like reasonable system performance, but mostly I am concerned about showing my users inaccurate results before all of the steps are complete. This currently requires workarounds and complexity, and things like “add a pause before next action” don’t help.

I’m only now finding solutions, but I can imagine people new to Bubble might be frustrated to discover that they are working in two worlds, one very synchronous and event-driven and another that is asynchronous and somewhat unpredictable.

Haven’t had problems with searches so far, but my data set is still small.

1 Like
12

Would it be possible to see your website? I assume as it went viral that it’s public.

It would be great for us to know what are the limits. How you app compares to ours to see how much road we still have before we reach the cliff.

4 Likes
13

I agree. You have most likely a wealth of information and practices we can all learn from.

2 Likes
14

Yes, I think removing restrictions on recursion would be a great help in the short term.

1 Like
15

Yes we have a huge restriction.
We reached the point when everything has been developed and we want to add more, but we can’t because of current performance. And we have no ability to solving them. There is just simply nothing that we can do. It feels like our business is not even open because of the slow performance.

We are at the mid-stages of developing our current app outside bubble but we are still using the bubble app for now. It’s not that bad by the way, it feels like an app from 2012 it just happens to be 2018 now, and people expect an app that responds like an app built in 2018.

It could also be that the flexibility of bubble becomes it’s own burden.
We might have not built our system the best way possible because of the flexibility, but I just don’t know.

The internal bubble team provides a free performance check when you ask and they go through your workflows to see if there is anything in particular that’s slowing things down.
That helped in the past to discover some low hanging performance issues but they also required us to remove important features that bubble just couldn’t run without compromising performance.

Remember this: look at bubble in it’s current stage as a great prototyping tool and if you start receiving traction, start building it with code right away.

With that said, I believe that Josh and Emmanuel will do amazing things in the coming years and these issues will be resolved, I believe that a fair and honest chat about performance can only help transition into the next chapter of Bubble and start finding solutions to these issues.

If I was them, I would put everything aside and really focus in on one thing: performance.

16 Likes
16

Thanks @feee :+1:

1 Like
17

Yes I agree, we need performance to be the only priority at the moment!

7 Likes
18

Agree!

Unfortunately, my app doesn’t have that many users, but performance is constantly on my mind, and half of the time I do consider whether it is worth risking the effort and then face issues described here.

To be honest, sometimes it is just embarrassing to present my app to potential clients and make them wait for my app to refresh the data and do what is expected. It is 2018.

The most upsetting thing here is what seems to be a fact - paying more to Bubble (supposedly adding capacity) doesn’t solve the issue.

2 Likes
19

Hey @feee - first of all congrats on all the user numbers, those are amazing! Bummer about the slow performance though, so I wanted to give a few basic performance optimization tricks that we’ve learned over time, in case they are helpful (you might already know these):

  1. Database redundancy: If you have 2 objects - a project and a task, you might have a “project” field on the task object. You may also want to create a “list of tasks” on the project object, that way you can access the project’s tasks directly instead of doing a search.
  2. More database redundancy: If you have 3 objects - a project, a task (that has a “project” field), and a message (that has a “task” field), you may also want to have a “project” field on the message object. That will a) help to make your searches faster because you don’t have to do a nested search and b) allow you to create privacy rules that will in turn also speed things up (as they will limit the amount of info that’s returned by the server).
  3. Empty search expressions: One issue we ran into at some point is that we had a search in an RG where a constraint was empty for a couple of seconds while the page was loading. As the result, the search’s results were 100x what they should have been for those couple of seconds, which slowed down the whole app. That’s easily fixed by putting the data source of that search expression as a conditional when that constraint isn’t empty.
  4. Don’t use any advanced filters as they require downloading a lot of data in the browser. You can usually get around using those by adjusting the data structure.

Vlad
AirDev

32 Likes
20

I’d say that these are good tips but don’t expect magic, we did these, and if your data structure is set as described by vlad, it does help. This is what I’d call the low hanging fruit. But once you have the data set like this, and you are still having performance issues, then there is not much left that you can do. (unless you are a techie and you can build custom plugins to go around limitations - I’ve hired that person, we built custom plugins and we made some things faster - but why am I paying the full price of a software engineer to go around bubble limitations when instead I could pay the same to have my own code?!)

3 Likes