Tutorial: How the order of your Conditions affect their performance

Tips
1

Bubble introduced a change in July of 2021 that affects how conditions are evaluated. They used to be read in full even when it wasn’t necessary, slowing down your app unnecessarily. After the change, Bubble skips the following conditions if an earlier one has already provided the needed response. This in turn affects how fast those conditions can be evaluated - sometimes in pretty noticeable ways.

This tutorial takes a look at how you can exploit this update and structure your Bubble conditions for better performance.

9 Likes
2

@petter Great article as always!

I was aware about the change mid last year (order of conditions). And certainly applied it mostly on elements.

Your article’s great points on this same subject but adding server vs client and element vs action considerations shed even more light going forward :smiley:

Thank you!

1 Like
3

Thanks @cmarchan :slight_smile:

Optimally, Bubble should optimize for performance on its own and prioritize client-side conditions over server-side in my opinion - to give devs one less thing to think about (and a lot less legacy condition expressions to correct!) - maybe that’s an idea for later @allenyang

1 Like
4

It will be interesting to see how things unfold @petter

The founders see Bubble as a programming language. It is tough to balance where to break through that. :thinking:

5

True!

But there are plenty of examples of Bubble not giving devs full freedom in order to maintain performance, such as the lack of loops (and delayed opening up of back-end recursive workflows). So there’s definitely a history of protecting users against themselves in terms of performance (which makes sense for a platform like Bubble imo).

That being said: there could be plenty of good reasons for not making the change, so I’m not pretending it’s a well-studied case with a final conclusion here - just a quick observation and suggestion.

2 Likes