Having a lot of Users loading your Bubble.io app at the same time can be a tricky problem to solve as it creates a capacity spike.
2024 Q4 update: after Bubble introduced the workload metric, capacity is no longer an issue. All apps run at the maximum available performance at all times, instead of being throttled. In other words, there’s no longer any reason to upgrade your plan to get an increase in performance/capacity. The flipside of that is that you may experience that a sudden spike in traffic or server work can consume all the available workload, and – worst case – your app can go offline. I’ll return to this point in a section at the bottom of this article. For those who have read the article before, I have removed all mention of capacity, as all apps have now been moved over to the workload system.
Bubble’s plans include a set number of workload units (WU). Workload is a pricing metric that calculates how much work the Bubble server is doing to keep your app running. More Users at the same time and a higher volume of workflows or more complex workflows executed means that a higher number of workload units is spent. In scenarios where you expect a sudden spike in traffic, you should prepare your app in multiple ways:
- Unless you want your app to go down, you need to make sure you have enough workload available to power the app through that spike
- You may also look at alternative ways to handle or even divert the traffic, to make sure that your app can handle it and to reduce the WU spent
Imagine hosting a conference where your Bubble app is used to register attendees and guide them through the event. The app is designed to handle various tasks, but at 8 a.m., as the doors open, all 5,000 attendees attempt to register their arrival simultaneously. What happens in this scenario?
Such a sudden spike in activity could consume all your available workload units within minutes, potentially causing Bubble to temporarily disable your app. This downtime would render the app unavailable at the exact moment it’s most critical. If the workload increase were distributed more evenly across the day, you’d have time to react and address the issue. However, the nature of spikes is that the surge happens all at once, making it difficult to manage in real time.
Typically, the app’s workload consumption would peak between 8 a.m. and 8:30 a.m. as attendees register en masse. After this initial rush, usage would likely normalize throughout the day as attendees interact with the app more sporadically. Preparing for such spikes in advance can help ensure your app remains operational during these crucial moments.
The chain reaction effect traffic spikes
Workload has transformed how Bubble manages capacity. In the past, sudden traffic spikes could result in timeouts and cause your app to go offline. Workload offers a more flexible approach: Bubble will do its best to operate your app at full capacity for as long as you have available workload units.
However, even with this flexibility, a massive surge in traffic can still overwhelm the server, making it challenging to accommodate all your users. This can create a self-reinforcing issue: as the server struggles, performance can degrade further, leading to slower response times and more strain as users attempt to reload or retry their actions, compounding the workload.
While workload eliminates some of the rigid bottlenecks of the old system, managing and preparing for sudden spikes remains essential to ensure your app runs smoothly during high-demand moments.
Put yourself in the shoes of the User: what do you do if the application is unreachable just when you need it? Well, if you’re like most people, you will keep refreshing the page or re-opening the app in a desperate attempt to gain access. Since Bubble doesn’t have any offline capabilities and relies 100% on the server even to render the page, you’re not just faced with a one-time page load from 5,000 users, but potentially an avalanche of attempted reloads.
What this means from a workload perspective? First, it can mean that you are consuming all the allotted WU in your plan within minutes of opening the conference. Keep in mind, we don’t count the number of actual Users trying to access the platform: we need to count the number of attempts to reach it, since each session requires the same amount of workload regardless of who the User is. So if 5,000 Users are attempting to connect at the same time, and they all refresh the page three times, we’re no longer dealing with 5,000 sessions, but 15,000. Over the course of a few minutes, each User is likely to try to refresh the page more than three times – perhaps repeatedly trying as much as 10 times, in which case our volume of sessions has grown to 50,000.
No wonder Bubble is struggling!
So even if you don’t spend all your workload instantly, a sudden spike that gives the server too much work can easily turn into a chain reaction where the number of Users seems mindboggingly much higher than the actual number of participants. You may check your Bubble logs and and compare it to an analytical tool like Google Analytics and get wildly different results, adding to the confusion. From a performance point of view, that same chain reaction is making the problem worse than it initially was.
What to do?
How to handle sudden traffic spikes
To be clear, this is not a Bubble problem; any platform that relies on a server with a set amount of capacity will struggle if that capacity is overspent in sudden spikes. As we’ll see, the answer can sometimes be solved in Bubble, but other times we need to look at external solutions to reach our goal. Let’s have a look at some different solutions.
Make sure you have enough WU
There are three main strategies to ensure you have the workload units (WU) necessary to handle spikes in app usage:
- Upgrade your plan: Increasing your plan level will raise your allotted WU. While this ensures a higher baseline of available workload, it might be excessive if you’re only expecting occasional spikes.
- Enable overages: This feature allows Bubble to automatically add more WU as needed during high-demand periods. It’s the most flexible option but may not be cost-efficient. If you’re unsure of how much WU is needed, enabling overages once during a spike can help you measure demand for future planning.
- Purchase WU packages at a discount: If you have a clear estimate of your WU needs, you can buy additional WU in bulk at a lower price. This approach is cost-effective for predictable, recurring spikes in usage.
While I personally believe WU costs are not as prohibitive as some users perceive, managing hosting expenses is always a smart practice—especially if spikes are frequent. With that in mind, let’s explore alternative strategies to help optimize workload usage and control costs.
Load an initial lightweight page
What page do you show when your Users open up the app? Is it a complex, single-page application or a simple, lightweight page with just a few elements and workflows? The more complex the page, the more workload Bubble has to spend for each User loading it. By giving some thought to the complexity of your initial page, you can reduce the total load on Bubble’s server.
Here’s a typical example: by default, the app loads the app’s main page. It’s a fairly complex single-page application with several workflows executed on page load and perhaps up to hundreds of elements that load data through searches. Bubble quickly discovers that the User is not signed in, and proceeds to redirect them to the sign in page.
What could we do instead? We could turn that scenario around and direct the User to the sign in page first: if they are already logged in, we can proceed to redirect them to the main app. This way, all the Users that are not logged in will not spend the extra workload needed to load the main page, but will only load the lightweight sign in page. Since users spend different amounts of time logging in, you can naturally spread them out over a few minutes, reducing the sudden load on the server.
Check that you are redirecting correctly
Speaking of redirects, did you know that redirecting a User to a different page in Bubble happens in two different ways? A redirect can be done client-side or server-side.
Client-side means that the redirect is happening on the page by Bubble running a snippet of Javascript directly in the browser.
Server-side means that the redirect happens before the page is loaded, since the server redirects the User immediately after the browser requests the page
What does this mean for workload? Think about it: if an operation is to run client-side, it means that it first has to load the script onto the page and then run it. In other words, a client-side redirect will download the full page before redirecting, as opposed to redirecting the user before the page is loaded.
This means that a client-side redirect will load two pages, but a server-side redirect will only load one. Naturally, the latter requires less processing power from the server.
How can you tell the difference? Bubble will attempt to do a server-side redirect whenever possible, but the more complex your page loading is (actions and conditions happening as the page loads), the more difficult you’re making it.
You can use a tool like SureOak’s 301 redirect checker to check how your page handles it. If it returns a 301 or 302 code, the redirect is done successfully server-side, but if you get a code of 200 it means that the redirect happens client-side.
We go into a lot more detail on redirects in The Ultimate Guide to Bubble Security.
Minimize the number of page load workflows and searches
Do you have workflows running on page load that spend WU? Try to reduce the number of page load workflows and spread them out over time instead. The same goes for Searches and Repeating Groups: instead of automatically loading them on page load, think about how you can spread it out over time: instead of showing a Repeating Group immediately, can you require that the User navigates to it first with a click or two? That way, you spread out its loading over time. Some users may never access the Repeating Group at all, saving thousands of searches.
Think about how your page design affects your app’s performance – the more processing power you require on page load, the more workload will be spent to serve up the page to thousands of Users.
You can use tools like Chrome Developer Tools to investigate what kind of workload you are giving the server on page load. Read more in our guide on Bubble and DevTools here.
Use third-party solutions for things like chat
Are there parts of your app that you can outsource to a third party? If you have a chat window built in Bubble for example, could you replace it with an external service instead? That way, you are spreading out your capacity on several different servers instead of relying on Bubble for everything.
Set up a virtual waiting room
If all else fails, you can also set up a virtual waiting room. These are external pages that place your Users in a queue during the busiest times to avoid overloading the server.
Services like www.crowdhandler.com lets you customize your waiting room to match your brand and can even monitor your page in real time to avoid both overloading the server and sending too many Users into the queue. You can even set up priority queues for your most important Users and custom templates for different parts of your application.
Lastly, it will monitor your site for suspicious IP addresses and focus on giving access to genuine users instead of bad actors. You can see a range of different virtual waiting room services on G2.
Conclusion
Sudden spikes in Users can be a tricky challenge to solve, since your app’s workload can be spent within those few minutes where everyone wants access. Unless you have additional WU available, the app may go offline, wreaking all sorts of havoc in both the online and offline world. Upgrading your plan just for those short bursts can feel excessive and may not be enough to solve the problem.
Think about what kind of load you are putting on the server the second a User loads your app. Are you loading a heavy page? Do you have a lot of workflows running as soon as the page loads? Are you redirecting incorrectly?
Finally, think about how you can spread out the server work 1) over time and 2) over different services, by using third-party services for things like chat and even considering a virtual queuing system to avoid the overload altogether.
To learn more about how you can optimize your Bubble app for performance, check out our book The Ultimate Guide to Bubble Performance and our shorter listicle 6 ways to improve your Bubble app’s performance. To learn more about Bubble security, including the different kinds of redirects, you may also want to check out The Ultimate Guide to Bubble Security.
Happy building!
