Cut Your Bubble Load Times in Half with This One Advanced Trick (Most Devs Miss This)

This one trick can slash your bubble page load times by 50% or more and reduce your bubble bills significantly. But most bubble developers don't even know it exists. I'm going to show you how to set database caching, an advanced technique that transformed our clients apps from sluggish to lightning fast. I've implemented this on tons of bubble applications that serve thousands of users. I'm going to share with you an advanced technique that you can use to improve your bubble applications page load speeds using database caching. It will improve your user experience, it will reduce your bubble costs, and it'll give you a big SEO push at the same time. So powerful technique, it's a bit complicated. That can make a ton of difference, but it takes some work. First, if you're keen on upping your bubble game, you really should get access to our no Code Resource Center. It's updated weekly with vetted plugins, how to videos, podcast episodes, great books to read, and a whole lot more. There's a link in the description below. You just have to put in your name and your email and it's completely free. Go grab that. Here's what most bubble developers don't quite understand. Bubble is constantly reconnecting with your database on every single page load. And think about that for a second. When a user loads your page, they're creating a live connection to your database. They're polling that database constantly to see if the data is changing, and it's basically repeating all of the work every time the data changes. And every time it does that work, it's charging you workflow units. And this is actually awesome if you're dealing with time sensitive, frequently updating data.

However, what about all the data that is practically static? Talking about blog posts or header links, product information that doesn't change very often. What if I told you there's a way to cache those database calls so that you don't have to maintain all those contacts with the database every single time? This means that your pages will load much faster. And since bubble's not doing all that work, you're not paying for it. Let me just explain now an overview of what's happening in the background when a user visits your bubble app. Here's what normally happens. They request a page. Bubble processes that request, it queries the database, it generates all the JavaScript for your page, it renders the page, and that's when the user sees something. And that happens every single time that someone loads a page. With database caching. Here's what happens instead. The user requests a page Cloudflare, which works with bubble automatically. And you can also set up your own Cloudflare in front of that if you want, looks and says, do I have this data? Is it cached? And if it doesn't, we'll just serve it immediately. And if not, then it'll go to bubble and get it. So the difference in speed is dramatic. And we're also talking about the fact that Bubble, when it goes to your database, it uses its own algorithms to determine not only what data you're asking for in that moment, but it tries to anticipate the next pieces of data that the user might request. And it'll bring that over. And based on your privacy rules, it'll bring all of the data that's available to that user to the browser. And that's a lot of data going back and forth. And it's a lot of decisions being made. And with what I'm going to teach you, you decide exactly which pieces of data you're going to bring. You control how long it's been since you've calculated that data, and if it hasn't been that long, you just take the cached version, you send it back. So this makes the process more secure, it makes it faster, and it costs less workflow events because you're really only going to generate the data once every. And that can depend on you. You get to decide, am I going to cache this for 10 minutes? Am I going to cache it for 10 days? That's up to you. This works great for data that doesn't change a lot. So blog posts, product descriptions, categories, whatever you have on your landing pages, help documentation, that sort of stuff that's in your database, but it's not changing all that often. That's where you want to use this technique. You don't want to use it on transactional data. You're not going to cache every transaction, every time you make a sale and stuff like that. That doesn't make sense. That won't help you at all. So let me walk you through what we're going to do, because it is work. This is going to make things different and it is a unique take on how to handle this. You're going to create backend workflows for each query that you're going to be caching. And that query can be accessing one table, or it can be accessing 50 tables. That's up to you. You decide that backend workflow is going to generate a JSON structure of what you're going to return to the browser. And if you don't know what a JSON structure is. You'll see it here when we start looking at the workflows, but you're going to need to learn about that and it's outside the scope of this video. Said this is going to be a bit technical. Step two is you're going to create an API call in the bubble API connector for each query. So that is what is going to be publicly available to be called. And then you're going to change your front end to use that API call. So you're no longer going to actually communicate directly with the bubble database. You're going to communicate directly with your API that you've created specifically for this function. And then the next step four is just to monitor how things are going and make sure that everything's working well and look at how your workflow unit consumptions have gone down. And just keep looking to see if there are processes that make sense for you to cache to keep reducing your workflow units. So let's jump into the bubble builder and actually see this working in action and how it's set up. So here we have a API called DB1Art Single. This pulls all the data related to one blog post from my database. And in this case I'm using two keys. They could either pull it by the ID or by the slug. Not really relevant here, but that's what we're doing in this case. And the response is a JSON. It needs to be exposed as a public API because otherwise we won't be able to call it. This workflow can be run without authentication because Blog post There's no reason for me to be checking that. And it will ignore privacy rules as well. And it will work with a GET function. So that's important because that's going to allow us to use it as a data function in the front end. What it does is it's going to trigger a custom event which we're going to see in just a moment that creates JSON if it needs to create it, and then it's going to return the data. So this is a really simple backend workflow. Let's look at the custom event and what this does is it's going to create a row in a table that I've created called XML files. That's just where I store the JSON because I want to be able to say, hey, if it's been less than 10 minutes, don't generate it again, just use the one that I've got stored. That makes sending the data just as simple as one call to the database and returning it really fast. In this case I do a little housekeeping and I delete the old ones, not all of them, but like four or five days back so that those files are just growing and growing. And I return the data so that I don't have to look for it again in the future. How does this work? The first thing it does is it's going to call the custom event that we just saw. Only when I look for the first one. So I do a search for this type. It's article single I use. I look for the ID or the slug. I order the by date descending so I get the newest ones first. I look at the first one and take its creation date and I add. In this case I'm doing one day, so I'm adding one to it. I have that in the option set there and I look and see if that's less than the current date time. If when it was created is less than a day before the current one, then it will run this, make sure that one day has gone by so I can create a new one just in case. And then what I do is, is I return and I look and see did this come back empty? Because if it's coming back empty, it's because it didn't execute. I just look for the first one in the table and return its data. And otherwise I just return what I get from the custom event. And I'm going to do this for all of the tables that I decide, all of the functions I want to cache. I'm going to have a similar structure. I'm looking for just the articles and I'm just pulling in data and I'm creating XML file and a JSON structure. So this is my JSON structure that I've created and has the title, the description. And I've been really careful to format all of these as JSON safe. So the quotes and characters, estranged characters are escaped out. Doesn't create any problems for me. I can do lists in here. So I've got topics. This is a list. That's when it's got square brackets. If I needed to, could do a search on another table and pull that in and put in to this structure as well. So I could do all of. I could do as much as I want. This could be as complicated as it needs to be. And what I do is I return this entire structure, I store that in my XML file and that's what I return. That's the first part of doing this, is to create A backend workflow for each query that we're going to do. Now we have to make that backend workflow available to the rest of the world because we're going to call it from the API. And so there we're going to go to plugins and I'm going to go to the API connector and what I'm going to do is I'm going to go to my database cache here, I'm going to expand this and you can see here, let's go to article single. I'm going to expand this out and you can see that it's being used as a data function. So that means I can use it anywhere in bubble as a data call. And it's not in a workflow. It is a JSON type structure that comes back. The get is going to be the URL. I'm passing this as a parameter because I want to be able to control version test and version live from my front end. We'll see that in a minute. And then I'm either passing you the slug or a unique id. Because these are optional, I allow them to be blank. And really important here is I am going to include a header called Cache control. This is going to tell Cloudflare if I'm using my Cloudflare or the bubbles Cloudflare that it should cache this API call. So it is got a max age here by seconds and smacks age which is for the server side is even larger. This means that it tells the user's browser to cache this and also tells the server cache to cache this. So this is going to make an extra level of caching between this API call and the user. Once I've done that, I'll initialize the call and it's ready to set up in the front end. So now we need to go to our front end and actually see how we're going to do this.

Go to the A page, which is the article page. We have a structure here that says art, which is a group. In here is of type article single article. And what it does, its data source is database cache article single. So that's the API call I've created in my API connector.

The first article that it brings back, in this case it only brings back one, but because the structure has a list in it, it considers that as more than one. And I always get the first one. So this is going to bring back that JSON structure. The content here is going to be pulling the data from this.

Database structure that it's received. So it's not going to call bubbles database at all. It's going to go and make the API call. It's only make it once. Let's cache it in the browser. And then all I have to do is reference art, its data source to get all of the data out of here and populate the different fields on the page. This works great also for repeating groups. So if you have a list of articles, you could just pull that in as a list. You can set the content of your repeating group to an API call and it's your API call so you know exactly what's coming back and you can just go into each item and put them into the cells of the repeating group. Works the same way. So this will go through. We've seen the three steps. We create the backache workflow, we create the API call and then we adjust our front end to work with that API call. And that way it's going to be using our caching, both the caching we've set up in the actual backend workflow and the browser and server caches that bubble already has for us. So we're getting the maximum amount of caching possible for this data and you can control the times based on how we saw it before.

Now all you have to do is make sure everything works right. So you're going to check your page, make sure all the data is coming in. You could go to the developer tools in Google Chrome and go to the network tab and you can load your page and see that it's not pulling from the database, it's pulling from your API call. If you use the bubble debugger, you can inspect that element in the page and look at the results that you got back and just make sure that everything is working. In my experience, we've gone from before caching pages that were taking four or five seconds to load the data to under half a second to load the data. That's the kind of speed improvements you could get. So this really is powerful. Another way to verify this is to just check your bubble logs. You'll notice that your database queries have gone down, your API calls will go up. Obviously you're going to be minimizing the amount of work your bubble application is doing. So we had a customer that had a really content, heavy bubble application with literally thousands of blog posts, product descriptions, knowledge base articles, and their page load speeds were 5, 6, 10 seconds sometimes. And it was really pushing them on the limits of their bubble plan. They were going to have to upgrade. It was going to cost them a lot of money. We were able to bring their page load speeds down to under a second. Their bubble usage decreased by 50%. So that's real money in your pocket. And because the pages were loading faster, SEO was better. User engagement increased by 35%, all from this one technique. And the beauty of this is that it scales. As your application gets more traffic, the benefits actually multiply. So instead of bubble working harder and harder with each new visitor, you're shifting that work to Cloudflare. You're shifting it to really optimize database calls that are in the back end so that your front end is really lean. I think that this is a powerful technique for certain scenarios. I do want to keep in mind here, this isn't awesome for really dynamic content. This works for tables that you don't change a whole lot. It doesn't work for user specific data because you're not going to be caching for each user. That's too complicated. You have to be careful that it is going to mean that your user interface is going to update slower. It's not going to be instantaneous. So if that's really important for you, then this probably isn't the path to go because you're caching and that means that it'll take whatever that time you've determined before it updates. Now you can go to the table that we've created, the XML table. Delete that specific article from the table and it will force a refresh the next time you load that page. So you do have some control over how that is handled, but it's not instantaneous. You do need to test JSON structures can be a little bit finicky. So you have to be really careful that you're making sure all of your variables are JSON safe and that you're, you're not creating something in the structure that breaks the structure and then it'll break your application. You'll have to debug it. But it's part of the work that you're going to get by doing this.

So I understand this has been a bit of a tech heavy video for you. This isn't light hearted. This isn't something I recommend for newbie bubble developers. It takes some effort, it takes some thought to understand the process. But I, I do hope that it has been useful for you. Be sure to use the link below and get access to our no Code Resource center. That's where all of our videos are listed. That's where our podcast episodes are listed. That's where you can find my books and other books that are really great and it also has our vetted list of plugins that we use in our applications. So these are the ones we've tested. These are the ones that we have felt confident enough to include in our resource center because they don't bog down your application and they actually work well. So I think that's a really great resource for you. If you found this video helpful, hit the like button, hit the thumbs up, the subscribe, stick around for future videos. I really appreciate you tuning in and see you in the next video.