Thinking Deeper About Performance in Bubble Apps

Tips
1

Thinking Deeper About Performance in Bubble Apps
Today, I’ve been reflecting on something many Bubble developers face but few openly discuss: performance vs. flexibility trade-offs.
Bubble gives us incredible power visual logic, custom states, reusable elements, database relationships but with great power comes… well, some slowness if not carefully optimized .

One thing I’ve been experimenting with lately is optimizing complex searches and conditionals, especially when dealing with nested Do a Search for and dynamic constraints. It’s helped improve page load times, but it also raises a question I’d love feedback on:

How do you approach structuring your data and conditionals to maintain performance in large-scale Bubble apps?

Do you lean heavily on backend workflows? External APIs? SQL integrations?

As I continue building client dashboards and scalable internal tools, I’m always looking for ways to build smarter not just faster.
To fellow devs and agencies: Let’s talk optimization.
What’s your top tip or biggest lesson when it comes to scaling apps responsibly on Bubble?

2

I have simple rules:

  • try not to store lists in fields
  • Split pages for different user roles
  • Identify which functions run the most and have them separately (reusable elements)

Haven’t had an issue yet

2 Likes
3

what?

4

Storing a list of datatypes in a field can be very useful to avoid using “Do a search” inside each cell of a Repeating Group. It improves performance and helps reduce Workload Unit (WU) usage.

1 Like
5

My only concern is that it is not scalable, if the list is under 10 entries then its all good, but that’s hardly the case

For example if you have a list of users who liked a product. Its all good when you have either 10 products or 20 users, but when you have 100 products and lets say 10k users the field needs to be a data type

3 Likes
6

I use my paid plugin Data Jedi for this. Allows me to be more flexible and get better performance and cheaper WU costs.

Use conditionals to load the data source leaving the main data source empty is one way. But in terms of data structuring, I use a Hybrid Data Structuring approach that allows me to leverage all 4 of the data types available in native bubble, the custom data types, option sets, API Objects and Plugin Objects. I am able to then make use of ALL that Bubble offers natively for data structuring and not just the main two of custom data types and option sets.

When you open up and use a Hybrid Data Structuring approach and use all 4 of the data types available you have so many alternative ways to structure your data and therefore optimized approaches for different use cases. For example, if I have a large set of data that is hardly ever, or never changed, I can store that as a JSON file on an option set attribute instead of individual data entries of a custom data type.

There are ultimately so many different approaches somebody would need to take to truly optimize for all individual use cases of data within the same app, and also depending upon the app structure like if it is a SPA or multiple page app.

None of the above. I do not use backend workflows to help with performance and data structuring. External APIs are case dependent, where for a dashboard showing Stripe checkout sessions, I might just use Stripe API for that, but again, it is case dependent. I do not use SQL, and just use the Bubble database.

Good thinking. Too many devs have some notion that building faster means better.

Think through each individual use case for the type of data and how it will be used, and come up with an optimized solution for each type of data and do not just believe a one size fits all approach is optimal.

If the list is more than 50 items yes, but less than 50 items it is fine to store them as a list

I personally do not do this and instead just use conditionals on elements and data sources. I prefer to keep the app lean with one feature set that can be used across all users, but in some situations, it may be beneficial to split pages.

This is case dependent. Usually it is easier to have functions that run frequently be a backend workflow and just schedule the workflow from where ever it is needed. Just makes it simpler inside the editor.

Yes, definitely need to think through the use case of the data to decide on correct approach of either a list field or a separate data type with a 1:1 relationship.

2 Likes