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.
Bubble’s plans at the time of writing this article are based on capacity. What this means is that upgrading your plan doesn’t necessarily make your app any faster, but it allows for more work to be done simultaneously: more Users at the same time and a higher volume of workflows or more complex workflows executed. If you have an application that keeps visiting above the 80% percentile of capacity used in the charts, upgrading your plan is a natural next step.
But what happens with apps that experience a sudden spike in the capacity chart; where the overall capacity spending is below 10%, but you reach 100% of your capacity within a short time period, leading to timeouts and error messages? This is a typical problem for applications that are designed to accept a large volume of Users accessing the app at the same time.
Imagine for example that you are hosting a conference that relies on a Bubble app to register User’s attendance and help them navigate the different sections of the conference. The doors open at 8 am and all 5,000 conference attendees open up the app at the same time to register their arrival. What happens then?
In many cases, the app will reach its maximum capacity from 8 am to about 8.30 am when everyone is signing in all at once – but then work just fine for the rest of the day when your User’s access the app more sporadically.
But during that half an hour of capacity overspending your app may be completely unreachable for thousands of Users.
The chain reaction effect of overspending capacity
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, the Users will simply see an error message.
So what does this mean? From a capacity perspective 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 capacity 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 a sudden maxed out capacity 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 capacity 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.
Upgrading your plan
The obvious solution is staring us in the face: upgrading your plan may give you the needed extra capacity to allow all 5,000 Users to reach the app at the same time, avoiding the chain reaction that completely blows your capacity. Using Bubble’s free boost feature, you can even test this for free by boosting your capacity right before the expected spike and see how the system handles it.
Still, Bubble’s plans are fairly expensive and upgrading it just for these sporadic outages may feel excessive and pricey. So let’s have a look at other potential solutions.
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 capacity 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. 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 capacity 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 our capacity? 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 take up server capacity? 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 Bubble will struggle 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 capacity is completely fine except for those few minutes where it isn’t. 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 capacity 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!
