Optimization checklist
Last updated
Was this helpful?
Last updated
Was this helpful?
Workload optimization sometimes touches on advanced Bubble practices. We recommend this guide for developers who are fairly experienced with Bubble, and it's useful to read up relevant chapters in the User manual to prepare for the process.
Client-side versus server-side
Understanding the difference between server-side and client-side is key to evaluating processes for workload.
Article:
Data In this article series, we cover how to work with different types of data in Bubble:
Article series:
Workflows
Article series:
Article:
Article:
Workflows is a part of the Logic series user manual series.
Article series:
Article:
Article: Dynamic expressions are used both to set up conditions, and are highly useful in different actions that you may want to add to your workflows.
Article: Conditions are used to determine whether a workflow or action should run or not, by checking whether something is true.
Article series: Using workflows to let the user navigate between pages and page sections.
The content of this article follows our workload optimization framework, which consists of the following points:
Complexity: How complex is a given process?
Repetition: How frequently is a given process repeated?
Volume: How much data is returned by the database in a given process?
To learn more about the optimization framework, check out the article below.
Article:
In this article, we provide a quick guide to optimize areas of your app where optimization opportunities are common. Each expandable box below includes a link to a more detailed article for deeper insights.
Before diving into each point, please remember that while these tips can serve as a checklist for optimizing your app, they won’t cover every unique scenario. Think of them as examples of how to apply the optimization framework by assessing whether a process is complex, repeated, or returns a high volume of data.
Full article:
Page is loaded events will trigger every time the Go to page action is used, even if the user remains on the same page, and it doesn't technically refresh.
Repetition: remove Page is loaded events, or replace them by another event that doesn't repeat as often.
Repetition: use conditions to ensure Go to page only runs once.
Loading data and/or performing searches on page load means that they are likely to be performed frequently.
Repetition: instead of on page load, load data later (such as requiring a ).
Repetition: to stop invisible elements from loading data.
Repetition/volume/complexity: avoid .
Volume: set up your database in a way that returns less data
It can be useful to run workflows as soon as the page loads, but keep in mind that anything that happens on page load is repetitive.
Look for ways to make page load workflows lightweight
Complexity: reduce the number of actions.
Complexity: simplify dynamic expressions.
Complexity: Avoid .
Volume: avoid searches that return a .
Repetition: consider whether a workflow needs to run on every page load.
Repetition: check whether the Go to page action forces a workflow to run more often than you anticipated.
Redirecting users to a different page is common in cases such as when the user is not logged in. Redirection can happen server-side (before the first page is loaded), or client-side (after the first page is loaded).
Performing redirects server-side means that no workload is spent sending the page HTML before the user is redirected.
Complexity: keep redirection events as straightforward as possible, such as using User is logged out with no conditions. When Bubble doesn't need to check anything on the page, it can redirect the user immediately instead of .
Many apps aggregate data in different ways (such as counting or calculating a sum or average). This is often done through a data source like Do a search for in combination with an operator like :count, :sum, or :average.
Repetition: considering calculating the numbers and storing them somewhere, instead of redoing the calculation every time they are displayed.
Repetition: consider not showing data until the user asks for it through interaction such as a button click.
Repetition: use conditions to avoid querying the data until an element is visible.
Complexity: set up the dynamic expression with as few sub-expressions as possible, and avoiding nested searches.
Searching for data is on its own not an especially heavy database operation, but we can use the optimization framework to determine whether a search spends a more significant amount than is necessary.
Complexity: avoid nested searches.
In repeating groups where each row contains a second search.
In search expressions, where a constraint or field contains a second search.
Complexity: avoid advanced filters.
Advanced filters (using the :filtered and :advanced operators) can substantially increase the WU needed to complete the query.
Volume: be mindful of structured and unstructured data.
Structured data is short, to-the-point data like names, phone numbers and emails.
Unstructured data can be long and "heavy", like blog posts, articles and product descriptions.
More text means more data to download, which translates into spending more WU.
Repetition: Be mindful of how often a search query is repeated
Searches on page load are naturally loading every time the page loads
Search results ; you don't need to perform another query for updated results.
Identical searches on the same page are only queried once, but queries in workflows are performed each time the workflow is executed. Consider using search results that have already been loaded when possible.
Full article:
Full article:
Each action that interacts with the server may add some WU to the calculation. Additionally, more actions can increase the total size of your app’s code. While this doesn’t affect WU consumption, it can lead to slower page load performance.
Complexity: look for ways to reduce the number of actions.
Complexity: look for dynamic expressions that are more complex than they need to.
Containing nested searches or advanced filters.
Even a low-impact workflow can spend considerable amounts of workload if it is repeated frequently.
Repetition: be mindful of using events like Page is loaded, Do every X seconds and potentially Do when condition is true, especially when they contain database operations such as searching or changing data.
Repetition: for particularly resource-heavy operations, find ways to encourage users to run them less frequently.
Working with lists, such as Make changes to a list of things and Delete a list of things are of course sometimes necessary. Still, keep in mind that it manipulating a list of things consumes more workload than a single thing.
Volume/repetition: avoid making frequent changes to a list of things.
Repetition: consider using instead of and when possible.
These two methods of performing bulk operations can often produce the same outcome, while one consumes a lot of more WU than the other.
Repetition: using recursive workflows forces Bubble to re-schedule the workflow a lot of times, whereas Schedule API workflow on a list will schedule all the workflows in one operation. In other words, Schedule API workflow on a list spends less WU and is the recommended method from a WU perspective.
Bulk operations are sometimes necessary, but are among the most WU-intensive tasks you can give the server.
Repetition: be mindful of how often you run a bulk operation. Optimally, they should be rare.
Repetition: Smaller bulk operations can sometimes be more efficiently handled by Make changes to a list of things, rather than Schedule API workflow on a list/recursive workflows.
Complexity/repetition: optimize bulk processes to not do more work than they absolutely need to.
Look for actions that could be repeated just once (such as on the last cycle, as opposed to on every cycle)
Pass lists as parameters, instead of performing the search query in every workflow
Set up conditions to be as lightweight as possible. For example, a condition that includes Do a search for may consume an unnecessary amount of WU
The database trigger event is a powerful feature for ensuring database integrity, but since they can trigger frequently, they can also potentially consume a significant amount of WU.
Repetition: set up database triggers with conditions that ensures it doesn't trigger too frequently.
Complexity: ensure that a database trigger event and its actions and conditions don't perform complex queries such as searches with :filtered and :advanced operators, and nested searches.
Repetition: sometimes, database trigger events can be combined into one. This lets you perform the condition on the event only once, and may also make the actions inside more lightweight.
API workflows and Data API endpoints that don't require authentication can be repeatedly accessed.
Repetition: As a general rule, inbound API requests to your app should require authentication, to avoid anyone simply calling them repeatedly.
Volume: avoid sending more data than you need via the Data API by setting up privacy rules and protect fields that should not be returned by the database.
Full article: