Over the past month, our team at Airdev has studied Bubble’s new Workload Units (WUs) consumption model extensively. As a result of this effort, we’ve put together a free WU Optimization Guide that we would love to share with the Bubble community. This guide includes best practices for building scalable, performant, and cost-effective applications in Bubble.
In the guide, we’ll cover different methods we use to consume fewer WUs. We’ll walk you through how to:
Create better search expressions
Prioritize client actions and only use server actions (backend workflows) when you need to reuse the workflow in multiple places
Set up conditional statements in the right order
And more
If you have any questions, please feel free to leave a comment below. Happy building!
Thanks for doing some research and saving us time from having to do that ourselves.
One suggestion for people that don’t want to use a button and still want to have the same feel as autobinding.
Auto-binding fields
We’ve experimented with the consumption of a binding input versus modifying the same thing with a standard input and a button and a “Make changes to the thing” action. We did the modifications on some fields of the Current user
Performing an auto-binding operation in one Current User field consumes 1.05 WU
Modifying several fields in the Current User consumes 1.12 WU
Based on those numbers, saving more than two fields is cheaper using a button and a “Make changes to a thing…” action than using auto-binding fields. Therefore our recommendation is to avoid auto-binding fields except if there is only one field to modify (or if the UX absolutely needs the auto-binding feature), if you need to modify two or more fields, use a standard input and a button.
You can right click on an input and edit the workflow from there. Then you don’t need a button.
Just a quick note about the search:count is 0 compared to search: first item is empty example…
Search: first item is empty will always perform a search (0.3. WU) and retrieve the first item from the database if there is one (0.015 WU plus the cost for the amount of data - so a minimum of 0.315 WU - and on heavy database items it can be 2-4 times that - 0.69 in your example)…
So it will always be more costly in WU than simply checking the count - which only requires an aggregate search, and doesn’t retrieve any data - so only ever costs 0.2 WU
There seems to be a bug in Bubble, with the way the number 0 in the expression search:count is 0 is evaluated, which changes the aggregate search into an actual search and returns the first 10 items - hence why it costs exactly 10 times more in WU in your example (once you deduct the cost of the search itself) than the expression search: first item is empty
But the issue seems only to be with the number 0 (and only when it’s manually typed into the expression) - any other number used in the expression results in an aggregate search (as expected), and a WU cost of only 0.2 (as expected) regardless of the size or amount of data involved.
In any case, the expression search:count < 1 will always be a more WU efficient way to establish this than search: first item is empty (even when there are no items returned by the search, search: first item is empty will cost 0.3 WU whereas search:count < 1 will cost 0.2 WU).
Question: How do you achieve this? For example, retrieving the users role or email address?
Current User
Bubble always downloads the Current User on each page, so it’s important to keep that in mind. If there is a value related to each individual user that you will need frequently, consider storing it in the Current User. This can save you WUs because the data will already be accessible in the browser when needed.
Great question, @tpolland! Whatever fields you create on the User object can then be accessed for the Current user by using the “Current user’s [field name]” expression in Bubble.
Question: If the same search is repeated X times on the same page, does it use WU X times? For example, a dropdown (filter of an RG) with 4 options, each option is a search. Does selecting an option each time generate a WU consumption?
If the search is the same, Bubble only does one. But each time you trigger the search, for example changing a constraint with a filter, the search will be perfomed again with the new data.
There’s definitely some useful information in here.
Does anyone know if there’s an effective way to work out which elements use search without having to click into every element? There’s an almost 100% guarantee that I’ve got elements duplicating searches from other elements, especially in conditional expressions.
