Why Your Bubble App Is So Slow (And How to Fix It Fast)

Is your bubble app performing like it's wading through molasses? Are your users complaining about slow page loads and glitchy interfaces? Here's the thing. Bubble applications are amazing for building powerful business tools really quick. But without mastering a few key concepts, your app can fail because it becomes frustratingly slow. I've been there, I've seen it, and I know exactly how to fix it. In this video, I'm going to walk you through my proven roadmap for dramatically speeding up your bubble application. I'll show you the easiest wins that will make an immediate difference, plus the fundamental architectural changes that will transform your app's performance in the long run. These just aren't theoretical tips. These are battle tested strategies that I've used on many applications to improve page load speeds by almost 70%. Before I became the no code wizard that you see today, I was struggling with a bubble application that was slow. Users were abandoning in droves. And after nearly 40 years in the tech industry, we can tell you this. Solving performance issues is about understanding the peculiarities of of the bubble platform, how it works, and not just some generic optimization tips. You really have to understand what's going on under the covers of bubble so that you can get your app optimized correctly. So stick around to the end because I'll show you how to access our complete bubble speed checklist for free. The same one that we give to our customers. So let's get in and let's get started. Step number one is understanding the two types of performance. There is perceived performance and there is real performance. And when I work with clients, the first thing I try to make them understand is that both of these are really important. Perceived performance is what your users feel, how responsive your app seems when they click on a button or they fill out a form or they take some sort of action. Whereas actual performance is what's happening behind the scenes. So database queries, API calls, backend workflows, front end workflows, all of those are affecting real performance. And the really fascinating thing is you can dramatically improve user satisfaction by first attacking perceived performance and then going after the actual real performance hits that you can fix in your bubble application as well. So it's like a magic trick that gets you some free time that makes things better for your user while you're doing the hard work of restructuring and making sure everything is really solid inside the framework, the architecture of your bubble application. So the first key insight is you need to optimize both how fast your application is and how fast feels. Because Both of those are critically important. Point number two is a list of low hanging fruit. Grab the apple off the tree that's right next to you and get that out of the way first, because these are going to be the steps that make the most immediate difference for your application. Let me tell you about a client who was about to abandon their Bubble application after spending six months developing it. They were ready to start over and go hire traditional developers because they thought that the platform just wouldn't work for what they wanted to do. Luckily, before they actually took that decision, we started doing some basic optimizations for them and the results shocked them. So what are the low hanging fruits? What are the things you can do quickly? First, images. One of the biggest Bubble performance killers is unoptimized images. I saw an application once that had 20 megabyte images all over the front page on the index page and they were just stuck in there. And Bubble does do some optimization internally for your images. So it wasn't maybe as bad as that might sound, but it was bad. Instead of just uploading the images as they come, resize them beforehand and then be sure to use the process with imgix. That is a function that you can put on any image on a bubble page. This will save you up to 70% of the image size without affecting the actual.

Resolution that the user perceives. So definitely do that. That is one of the big things you do. Second easy, low hanging Fruit is fonts. And this is really something that people don't understand is that fonts in a Bubble application can be problematic. The truth is that any font that you have installed on one single text field or input field somewhere in your application will cause Bubble to load that entire font file on every page of your application, regardless of if it's used on the page or not. It's just the way Bubble's built. And if you're looking at 250 milliseconds to download the font file and you've got five or six of them, that adds up quick. Also, icon packs are fonts as well. So pick one. I like just to use the standard Bubble icons because they don't consume anything, they're already in bubble. But if you decide that you want to go with another extra, don't use four of them, use one, pick one and stick to it. And it's really easy to go into the developer tools in your Chrome browser and look at the Network tab and you can see exactly how many fonts are being loaded on your page. And I recommend that you bring it down to 1. That's the optimal if you really have to use 2. But don't go more than that. I recorded a whole video on how to optimize your fonts. So that is an important low hanging fruit and then the third low hanging fruit. My pet peeve of all peeves is plugins. Get rid of as many plugins as you can. And the reason for this is because bubble also loads the definition of every plugin on every page that you load in your application. And we learned this the hard way with one of our plugins that we built that was amazingly powerful and monstrously large. And we realized it was loading almost 3 megabytes on every page load and idea, we had to redo it. We had to fix the plugin architecture to work in a different way. Some plugins don't really matter. Little ones that are like visual elements, a progress bar or slider or something, those don't really make a difference. But the big plugins that do a lot of complicated things, those are dastardly. So avoid them at all costs. Use the bubble native plugins first. So if you just want a couple of charts in your application, use the bubble native plugin. Why? Because it doesn't get loaded on every page because it was built by bubble and they don't treat those the same way. If you have to use another one, okay, use it. But be really cautious with your plugins because they will bog your bubble application down. Okay? Those are the three big low hanging fruits that you need to take care of. Now let's start digging into the fundamental architecture changes that will transform the performance of your bubble application. This is the really powerful stuff that separates the amateur bubble developers from the pros. This is where we go beyond just making app a little faster and completely taking it to a whole new level. So I once worked with a SaaS company whose application was taking 12 seconds to load the dashboard. And after implementing fundamental changes I'm about to share, we got it down to under three seconds and their complaints disappeared overnight. The first fundamental issue is to address database architecture. Most bubble performance problems come from a poorly designed database design. Okay? That is just the reality of it. That means you need to concentrate on your privacy rules so that you're not bringing a lot of data into the browser that isn't necessary. For each specific user, you need to separate your tables into the core tables and saddlebag tables that you only call on when it's absolutely necessary. Make sure to not bog down your user table with a lot of fields. That is One place you do need a saddlebag table that offloads off of the user table because the user table gets loaded on every page. Load at least one row. And so if you've got a gazillion fields in there, you're bringing a gazillion fields into the browser every time you load the page. That's a big none. So also be careful about list fields. So having a list of texts is fine. If it's going to have 10 or 20 texts in there, that's great. But if it's a a whole complex table structure and you've got a list of 500 of them, that's going to bog things down. So use another table and then do a search on it to bring those in when you need it, because there's really no reason to overload your tables with humongous list fields. The next fundamental issue is workflows. It's really important to understand what workflows need to be executed in the browser client side and what ones should be done on the server. This talks really specifically to perceived and real performance, both of them, because if you have a workflow that does a whole bunch of operations in the user's browser, they're going to notice that because the interface is going to be waiting for those workflows to complete. Don't do that. Move as much as you can to backend workflows that execute on the server. First of all, they will execute faster, and second of all, your user can go on with his life. He can keep doing what he needs to do and won't perceive all that work that's being done in the background. So really important to structure your workflows correctly. Be sure to use result of step one, result of step two to make sure your workflows go in order. I've got a whole video on how to optimize your workflows, so go check that out if that's something you want to dive into more deeply. And now let's dig into some more advanced techniques for power users. If you've implemented everything that I've talked to you so far and your bubble application still isn't quite there, or you just want to take it to the next level, let me share some advanced techniques that very few bubble developers actually know about. One is database caching. It's one of the most powerful underutilized features in bubble. Instead of repeatedly searching your database for some information, you can set up backend workflows that respond to API calls and cache them. And if you do that correctly, that will save you a lot of money on workflow units, but it will also make your application faster and you'll be able to very.

Finely control the exact data that you're passing back to the browser. One of the cool things that bubble does is it optimizes a lot on the front end. But one of the counterpoints of that is it is constantly polling the database. It's checking to see if there's new data to pull in. It's using algorithms to anticipate what data you might want next. And while that can be really powerful, it can also consume a lot of workflow units and it can slow things down if you're not careful. So database caching is a great way to avoid that. If you have any more questions, reach out to us here at ratio.dev. for example, I worked with one client who whose app needed to display basically the same set of products to all their users. And by implementing caching we were able to reduce the database queries by 95% because that data wasn't changing. So why not store the actual result of the query and just serve it directly and then refresh it once a day, or once every five days or whatever works for your business? Another powerful tool to do, and I briefly mentioned this earlier, is to get really familiar with the Google developer tools in the Chrome browser. You can dig in and see what files are taking longer to be served, what is slowing your application down, how often it's polling the database. You could order things by file size or by time to pull them in. So really get comfortable with the JavaScript console and the developer tools in your browser because they will guide you towards optimizing your bubble application, like having Superman's X ray vision there. Final point here is that this isn't a do once and leave it kind of proposition. Optimizing your bubble application is an ongoing affair. You're going to need to be monitoring it over time. And as it grows, as your data sets grow, you may need to go back and restructure a table. You may need to start caching a table that you didn't think you were going to need to cache. You may need to isolate a workflow that should be moved to the backend because it's slowing down the user experience. So using the analytics in your bubble builder and the developer tools in Chrome, you can get a really good idea of where your bottlenecks are and that's where you attack. But you need to also be thinking about performance before you do anything new. So before you implement a new feature. Ask yourself how will this impact performance test on slower machines? Don't test on your Super M4 Mac Pro with 500 gigs of RAM because it's going to be fast. Try it on a cell phone. Be aware that the experience isn't always uniform, and then take some time once a month, say, to actually study your performance analytics and see where you can make improvements. This holistic, ongoing approach is definitely the best way to conquer any performance issues you have in your bubble application. I've given you some quick wins. I've talked about some of the deep architectural issues that you have to take into account, but you can also get a whole lot more really great information by getting access to our free no Code Resource center. Go to ratio.dev It'll pop up there. It's full of plugins that have been vetted that won't bog your application down. It's got how to videos, it's got our podcast episodes, it's got great books to read, so definitely do that. Now. The links down below in the description so grab access to that. We update it every week, so that is important. It's always getting better. If you're struggling with performance issues in your bubble application you want our help, go to rayshow.dev and reach out to us. We'll be glad to set up a time to talk with you just to see what's going on. Thank you so much for watching this video. I hope you've enjoyed it. See you on the next one.