In this video, we dive into the art of balancing workload consumption and user experience in your Bubble app. Learn how the "Optimization Framework" – made up of three core pillars: Complexity, Volume, and Repetition – can help you fine-tune your app’s performance without compromising user satisfaction.

We'll break down each pillar and provide actionable tips to optimize your app as it scales. We’ll also explore key decision-making strategies and demonstrate real-world examples of how to reduce workload consumption efficiently, from page loads to backend workflows. By the end, you’ll have the tools to make informed decisions about where and how to optimize your app.

For more information on workload and other Bubble topics, please visit our manual.

The workload metric gives insight into how much server power your app is using. Think of it as fuel for your car: it shows how much energy we've consumed as we drive our app forward. But here's the interesting part: while we do want to be mindful of our fuel consumption, it's just as important to ensure that our app delivers a smooth ride for its users. In this video, we're going to discuss balance and learn how to optimize workload for your application.

Successful apps work really hard to hide how complex they are, but your users will not care how much advanced machinery is working under the hood as long as they have a smooth user experience that solves their problems quickly. This understanding is crucial as you plan for workload. You need to balance the user experience with the optimal workload consumption. The underlying point is of course that most apps need to increase workload as they scale in order to give their users the experience they expect. But, with careful planning and good design, you can avoid spending more than what is needed.

When it comes to striking the balance between workload and the user experience, you can think about decision making on three levels. Number one: save workload at no cost to the User Experience. If you can implement or change a process that saves your workload at no cost to your users' experience, well the decision is easy: you can go right ahead and implement it right away. Number two: save workload at a slight cost to the User Experience. This second level involves making a slight sacrifice to the user experience in order to reduce workload consumption. It's essential to understand that compromising isn't always negative, it merely demands careful evaluation. Number three: save workload at a major cost to the User Experience. And at the third level, we are making cuts or changes in the user experience that users may find to be reducing the overall quality of the app. If you find yourself at this level, you may want to start reframing how you think about workload. Remember: workload is here to be spent! You would never expect a car to run without fuel or electricity, right? If workload concerns compromising your app's primary function or its ability to address a specific problem, you might be placing too much emphasis on it. Remember: the main goal is for your app to effectively serve its users.

Workload is what powers your app. As your app scales and becomes more successful, it's expected that workload consumption will increase. This doesn't mean that your app is performing worse, it simply means that it's being used more! Optimization is about fine-tuning for efficiency, not reducing it to a level where your users' experience or application's abilities are negatively impacted. Since every app is unique, we need to take a more fundamental approach. Since all Bubble apps rely on a core set of tools, we can identify patterns that often indicate opportunity unities for optimization.

With that said, I want to introduce you to the Optimization Framework: an effective way to look for optimizations throughout your Bubble app! The Optimization Framework can be broken down into three pillars: Complexity, Volume, and Repetition. Let's break down each of these pillars and what they mean.

Complexity refers to the process you use to achieve a certain goal. Using the car analogy from before, excessive complexity is like driving from point A to point B but taking unnecessary detours along the way. Some examples that often lead to additional consumption here are: searches with intricate constraints and structure, workflows that use more actions than necessary, and nested expressions that are starting more processes without your full knowledge.

Next we have Volume. Volume is about out being aware of the amount of data the server is returning when you give it a request. Using the car analogy, excess volume is like driving from point A to point B while hauling unnecessary cargo that doesn't really serve a purpose. So, some examples that often lead to additional consumption here are: returning a larger number of records from the database than you actually need and returning a larger volume of data than you're using in your app.

And finally we have Repetition. Repetition is about how frequently a given task is being performed on the server, and taking a look at where repetition is necessary. Using the car analogy, excess repetition is like taking the same trip repeatedly when fewer trips would achieve the same results. Examples that often lead to additional consumption here are: performing searches or running workflows every time the page loads, updating data at a high level when a lower level could be sufficient, and setting up user interfaces that require a lot more data from the server where small tweaks in the user interface could reduce workload consumption.

With this framework, our goal is to empower you with the knowledge and tools to ask the right questions and make informed decisions about where and how you should optimize your app. By understanding these key principles of our Optimization Framework, you can identify the opportunities on your own. Start by asking yourself questions for each pillar. For Complexity: is this expression doing too much? For Volume, it's a question like: where can I decrease the amount of data being returned? And for Repetition: can I reduce the amount that this runs over time?

With these questions in mind, let's dive deeper into examples while relating them to the Framework. We'll start by looking at how we can optimize page load. Page load 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. Therefore, this would be a good place to look for potential optimization. Let's ask ourselves the question: how can we reduce the repetitiveness of this event? The answer to that question is that we have different options depending on the user experience that you want to deliver. Remember our decision framework from earlier? You might consider each option carefully as they can influence your app.

For example, we could remove a page load event entirely if it's not truly needed, or replace it with another event that doesn't repeat as often. To achieve this, we would add a user-driven event, like when the user clicks a button, giving our users control over when to run this workflow which might result in lower frequency. Of course, that only works for scenarios where the data is something you are okay with the user fetching. And while it reduces the repetitive nature of the page load event, it might ultimately still cost the same depending on how many users are clicking the button to trigger the event. Alternatively, if we keep the page load event, we can use conditions to ensure that the "Go to page..." action only runs once, preventing it from using too much workload.

Let's shift our focus to another crucial aspect of page load optimization: searches and volume. When you're loading data or performing searches, consider the timing and necessity of these actions. Instead of fetching all of the data during the initial page load, ask yourself: can I load this data later? If you need to get data on page load, consider setting up the database in a way that returns only the data that is needed. Whether it be by setting up a different data type that combines two data types together, or paginating your results, you don't need to fetch everything at once which will reduce the amount of workload. This optimizes for exactly the data that you need to load versus bloating the action by making it load unnecessary results.

Searches that trigger subsequent searches done repeatedly each time a user goes to a page is not setting up for efficiency because it would add unnecessarily volume and complexity in one swoop. Searching for data on its own is not an especially heavy database operation, but we can use the Optimization Framework to determine whether a search spends a significant amount more than is necessary. For example, be mindful of nested repeating groups where each row and each user triggers multiple searches. This can lead to excessive data retrieval and redundancy, making the process repetitive and volume-heavy. Or how advanced filters can substantially increase the amount of workload for the same reason; the server is doing a lot of work to complete the query.

Now let's look at another place where we can optimize: backend workflows. In many complex applications, backend workflows are essential for automating various processes and tasks. Optimizing for workload here is straightforward. Keep referring to the questions about the framework: how often is this workflow running? How much data is being processed each time? How many users trigger this daily, weekly, or monthly?

For example, recursive workflows are a common way to process large sets of data and while they have their usefulness, there is an alternative way to achieve optimization here called "Schedule API workflow on a list," abbreviated as S.A.W.O.L. In most instances, the S.A.W.O.L. action is a faster and more optimized approach for processing list data than using a recursive workflow. They are both methods for performing bulk operations, but recursive workflows consume a lot more workload than S.A.W.O.L. does because Bubble has to reschedule the workflow to run again and again whereas S.A.W.O.L. will schedule all of the workflows in one operation. S.A.W.O.L. removes the part of the repetition, and when optimizing for workload, it's a recommended method for handling bulk data in backend workflows.

While bulk operations can be necessary, they tend to be amongst the most repetitive and workload-intensive tasks for the server, but there are always other avenues to gain workload efficiency. For instance, 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" or recursive workflows.

Let's shift our focus to another area of optimization: security. While optimizing for workload is important, it's crucial to recognize that in certain cases security should take precedence over workload considerations. We'll explore two specific areas where you can optimize for workload, but when ensuring robust security measures is even more important.

One example that comes to mind is that inbound API requests to your app should require authentication to avoid anyone simply calling them repeatedly. It's common to miss securing your end points like this during development, so this is an area worth optimizing and it's always great practice to make your app more secure.

In addition, keep in mind that sending more data than you need via the Data API is worth avoiding. Make sure you set up Privacy Rules and protect the fields that should not be returned by the database or the wrong user. This results in a more secure app and a more efficient use of workload. You should always optimize workflows for workload without compromising security or user experience.

After reviewing these various optimization opportunities, it's important to recognize that not every situation requires optimization. For processes requiring heightened security, prioritizing security over workload is often the smarter choice. For more detailed information, please read through our Manual articles. There, you'll find similar content discussing this framework in more detail along with more examples like this that might be similar to what you need.

Remember, these frameworks are there to help as your app scales, and you need to optimize it, but every app is unique. Try to find the right balance for your app with these tips, and overall make sure your app functions how you need it to. Be sure to check out the rest of our series and subscribe for more videos like this. Let us know what you think in the comments!