5 Bubble App Mistakes That Are Slowing You Down (And How to Fix Them) - Nocode Wizardry

New episode of no Code Wizardry. And today we want to talk about the five biggest obstacles that we've. Well, that we typically see our customers facing when they're trying to scale their bubble applications or even just get them up, you know, up from the ground, you know, kickstarted.

These are the, the five big ones that, that really people struggle with.

You want to dive into them, right? Without any.

Sure. But I think before we get started, we should remind people to, if you want to up your bubble game to use the link that we put in the description and grab access, free access to our no Code Resource Center.

What. What is that?

It's updated weekly. It has plugins, it has how to videos, it has cool books to read.

Podcast episodes that haven't necessarily been recorded by us, but podcast episodes that we found interesting and that we believe can help you in your no code journey as well. A lot of them are about entrepreneurship and just business in general.

Yeah, there's a lot of good stuff.

In there anyways, that is linked down in the show notes down below. So just, you know, like Dennis said, go ahead and check it out. It's 100 free and we update that resource center every week. And with that said, let's talk about obstacle number one, which is that a lot of people, when they're playing and you know, when they're getting started with bubble, they come across this problem, which is that their app is too slow. What are some of the main reasons why bubble applications are slow?

So I think my biggest pet peeve, and it definitely speaks to newbies a bit, is the plugin below.

And there's. That reminds me of my WordPress journey because, you know, when we, we used to work a lot with people in the workforce space. And that is also one point of, one major point of conflict. Right. I mean, we've logged into websites where customers just love, oh, fixing problems that they may have by trying to install a plugin that tries to solve that particular issue.

And then there's conflicts. And I think though that in bubble there's even a more important thing with plugins is that even if you're not using that plugin on your specific bubble application page, it's being loaded into memory on every page. So you have to be careful about that. You have to understand that especially usually little plugins that do little visual things like a slider or a, you know, a progress bar, those don't really matter. But any more complicated plugin that has a lot of functionality, that uses external APIs, that does calculations and stuff, like that going to slow your dap down.

Which also goes to say that it's not. Look, it's not so much a problem of how many plugins you've got installed on your app or even on your website. Like if, if you're building on WordPress, for example, I've logged into WordPress websites with, you know, that have 80 different plugins installed on them, and there's some of the fastest websites I've seen in my life. They load instantly. But because of those, you know, those plugins that they're using, they've been well designed, they've been well built, and they don't bloat your website. And something similar happens with Bubble. I mean, if you're installing a plugin that is loading and firing up on every page, then you're going to have a problem. Yeah, and something similar happens with fonts as well.

Fonts are another big one. Yeah. And people don't understand. But if you use a font on one text field in the var farest remotest corner of your application, hidden away, where nobody even goes there, that font is loaded on every page load in your application.

How do you, how do you fix that? How do you not?

Oh, that takes wizardry, my boy.

So, I mean, how. How do we do it so that we make sure that we're only using the fonts that fire up when they're needed?

No, they can't do that. If you put it into your application, it's going to get loaded on every page load. The only thing you can do is not use them. So you just need to be careful. Don't put fonts, don't put icon sets into your application unless you really need them. And usually one app font is good enough, maybe two, if you want to be really sophisticated. But be really careful. Going back to plugins, sometimes plugins bring their own fonts in and you don't realize it. And sleuthing them out and finding where in your application that mysterious font lives, it's a painful thing to do. I. There's a video in the resource center that talks just about that. So we're not going to dig into the weeds, but it is a pain to go and find them. So the best thing to do is just not use them.

And one thing that you can do is spend a little bit of more time during the design process of your application, which is something that we do. We have our own team of designers that works with us. And what we do is we design applications that literally only make use of one font style that font style, because we are a particular fan of it, is usually enter Enter works really well because, you know, it looks really nicely on headings, it looks really nicely on body paragraphs. And we can rock and roll an entire design of an application with just that one font. Sometimes it changes, sometimes it's Montserrat, sometimes it's something else. But we're really good at designing application applications that can be powered by a single font. And it's still, you're still going to have that nice contrast from a design standpoint as to, you know, how do your headings look like in contrast to your body paragraphs?

And it looks, it looks pretty well.

You can design really nice looking applications with just one font.

Sure.

So something else that you know, you should probably talk about is database design.

That is the second or maybe the first biggest problem with many, many bubble applications if you're not careful about how you structure your database. If you use a lot of list fields with big lists, that's going to make things slow down. Bubble brings a lot of data into the user's browser on every page load based on what it estimates is going to be could be needed. It's really sophisticated in the way that it does that. But that can provoke a lot of data moving back and forth between the bubble servers and the user's browser and that slows things down. So you have to be really careful about how you do that. Also, set your privacy rules up well, because your database almost always has a lot of fields that aren't needed in the user interface, but they are used in the backend. Well, you should make sure that your privacy rules.

Don'T allow those fields to be served to the, to the client browser.

Can you talk about how we've implemented caching?

So that is a bonus advanced tip and it is something that has worked really well for us in some applications. It's not a universal do this and it works for everything. But when you have data types that aren't being changed frequently, so a blog post, for example, well, there's really no reason for you to be constantly pulling the data database for that content because it hasn't changed. And so by implementing database caching, and it's a little tricky and you have to do some work in your application to set it up and you have to be kind of know how to do it, by the way, that's going to be in a upcoming video. But it does allow you to control the data that is actually being sent to your bubble application. Bubble constantly pulls the database normally, but if you use caching, then that's not happening because it's going via an API call and once it's pulled it can be cached in the edge server and it's not even affecting bubble. So you're actually saving money from bubble.

As well because you're not making use of as many workflows.

Exactly.

Interesting. So I think that sums up obstacle number one, which is speed and people having problems with loading times stock. About obstacle number two, which is ranking SEO. A lot of people think that a, you're building a bubble, you can build great applications, but they're not going to be seen by, by anyone because you can't get them to rank on Google.

Well, you know that, you know, we've talked about this on numerous occasions and it is something that's really important and I think the message is to say first of all, bubble applications can rank.

We've ranked and we continue to rank for, at the very top of search engines for multiple applications of ours.

So yeah, it can be done. And even more importantly, your application deserves to rank. Yeah. So there are some peculiarities about using bubble and you have to understand them and they do affect SEO and you also have to do the work. There's, there's no, you know, although we do have a really fun, cute little robot AI powered robot that will help you. Surpy Serpy. Hey Serpy, call out to Serpy, maybe he'll bounce up in the middle.

There's still a lot of stuff that you need to do. You need to optimize your application. You need to really work on the internal linking structure. You need to work on how you set up your workflows. There's a lot of things that go on sitemaps, lots of stuff that you need to understand. But if you get it right, your application will definitely rank. It can and it does deserve to rank. And you know, here we are, Let us know if you need help.

So the summary is that yes, it's not as easy as just hitting a few checkboxes and just letting your app miraculously rank. There's a little bit of work that has to go into it, but it can rank.

It can and it will.

It can. And I like the authority there. Obstacle number three is the bugginess that often times comes with bubble applications. But I feel like that's just.

It'S not bubble, it's you, it's how you've built your app, which may lead to potential bugs.

Right. But sometimes it's due to just not understanding enough about how bubble works. On the, on the insides. I did a video not too long about synchronicity. And a lot of the bugs people have in their applications are due to the fact that they don't really understand how workflows execute. They don't go in order just because it's, you know, used to be left to. Right now it's down to, you know, top to bottom, and they look like they're steps that go consecutively. That's not how bubble works. It will, once it starts, a workflow will try to do every step at the same time.

It's confusing because from a design standpoint, when you're looking at that sequence of things that are supposedly happening in order, it is confusing. I can see how someone would think, oh, I have this very. This first step at the very top. So that's going to happen first. And then as things go and then it doesn't. It doesn't.

Or it does at sometimes and it doesn't at other times. Because you could be, you know, things may. When there's not any demand on the application, it may not really happen and you may not notice. And then when there's a lot of people trying to access your application, things go slower and those synchronicity issues become more important, that it's not a problem that can't be fixed. Bubble has the tools inside it to make sure that that doesn't happen. You just have to know how to use them.

Can you talk a little bit about the difference between front end workflows and backend workflows? Because I feel like that's also.

A main key point where a lot of bugginess comes into play.

It's funny that you say that, because sometimes when people ask me, hey, can you look at my bubble application? Just. And I'll go in. They'll give me access, I'll go in and the first thing I do is I look and see, are they using backend workflows? Because for me, that is a clear indicator of whether or not you're a good bubble or a bubble. Well, I don't want to say good, because you could be really good at. But if you're not using backend workflows, you're not a professional.

What's so special about backend workflows?

Well, first of all, they execute on the server, so they don't depend on whether or not your customer has A, you know, M4, Mac Pro, you know, Super Ultra processor with tons of memory. It doesn't matter if they're on a cell phone. It doesn't matter you know anything about, you know what browser they're using or how old their computer is because it happens on the server. So that makes instantly makes your application more responsive to the user's needs because it's, you're not asking their, their infrastructure to do work that isn't necessary. So that's just good practice. Everything you can move to the server, do so I mean, that's usually a good idea. Now if something needs to happen when a person clicks a button and it has to happen instantly, well, then that's in a client side workflow and that's fine. And you can have them work together. So a client side workflow can offload part of its work to a backend workflow. And that's perfectly normal and a good way to do things. So, yeah, that is, I think, an important lesson to learn.

What's so special about return values?

Oh, these are fun. This is something kind of new. I mean, you know, Bubble gets lots of splash when they do AI streaming and they do, you know.

Mobile development. Hey, Tony's hat's off. I don't have a hat today. But they do some things that are really cool and then nobody even really talks about them. And the ability now for a custom event or.

An API call to return a value is really useful. It will save you money if you set your workflows up right because you can have, you're basically creating local variables inside your subroutines so that you can, for example, do a search in a custom event at the beginning of your workflow and just return the results of that search and then you can use that, those results all the way through your workflow and you don't have to repeat the search. Well, guess what? You're not repeating the search. You're not paying Bubble more money and you're saving, you know, making your application more efficient. So yeah, I really think that custom events with return values are really slick.

What about back end transaction queues?

That's another advanced bonus here. So.

It talks back to the synchronicity issue that we were discussing. And within a workflow you can use custom events and you can use the result of step three, whatever, to control inside a workflow the order of operations. But what happens when there's multiple workflows? What happens when you have, you know, a user's making, you know, doing multiple things at the same time and those are firing off the same workflow on the same data? You know, it can get really messy and you know, they can step on each Other's toes. And this is one area that bubble doesn't give you a good solution for. Because even if you, you know, run a workflow or schedule a workflow on a list, that doesn't mean if that workflow does a lot of stuff, it can still be fighting between calls to access the same data. And if you have two routines accessing the same data at the same time, you can confuse the application. And so a backend queue is a way of making sure that your workflows execute in order to, and that they finish before the next one gets a turn. And it takes some effort, it takes some work. But we've got, we've got in that resource center a good guide on that.

That's how we've managed to crack down on finance track and make it more.

Calculating running balances is one area that is tricky to do. It took us a while to figure out. It did take us a while because it is complicated. Because, you know, if you have a person goes back and changes a transaction that happened six months ago, you've got to recalculate all those balances. And then while it's doing all those recalculations, you gotta be sure that nobody else is, you know, trying to do it at the same time.

All right, let's move on and talk about obstacle number four, which is a little bit more about design. And let's face it, a lot of people that are going to be using your bubble application or even your mobile application now that mobile apps are a real thing with Bubble, it means that your app needs to be mobile responsive.

Yeah.

I mean, websites have had to be mobile responsive since the last 15 years. It's no exception. Your app has to be responsive and it needs to work well on all sorts of mobile devices, whether it's an iPad, whether it's a smartphone.

And the truth is, a lot of applications should start off being mobile first. They should actually start off thinking about the mobile experience before the desktop experience.

So one thing that I've been meaning to do, and hopefully I'll get around this soon, is do a video around how we do design and how to, how we do, how we do mobile responsiveness here at ratio. But you need to store, you guys really need to stop, you know, low balling your responsiveness. I mean, building mobile responsive applications is really about math.

Yeah, it is math. It is.

It's about figuring out where your breakpoints are going to be as you scale down your screen sizes or as you scale up your, your screen sizes. And once you figure out what those scale points are going to be, what those breakpoints are going to be. It really isn't that hard.

No, I mean, get comfortable using columns and rows. That's a big deal with mobile responsiveness. And there really isn't. It's that complicated. But be careful, don't make 50 different layers deep because that will slow things down as well.

Custom styles inside bubble. Just double check and make sure that you've optimized things for mobile devices as well. If your H1 headings are 52 pixels big on desktop devices, then make sure that they look good on mobile devices as well. Yeah, these are simple things that you may want. Just double check, make sure that you're doing.

The responsive tab in the builder. Make sure that you add a custom breakpoint at 536 pixels just to make sure that. That, that is a breakpoint for tablets. That is a breakpoint. For now they're coming up with these foldable smartphones. It's just an nifty little breakpoint that you want to make sure you're checking. And then. Oh, one thing. For example, we can talk about option track here. So option track deals with a lot of tables today, but tables were not a thing like two years ago in bubble, right. So we had to do. We had to use repeating groups.

We started off with repeating.

We started off with repeating groups, and we moved all those repeating groups over into tables.

I don't know if all of them, but most. Most of them, yeah. And I'm pretty happy with tables. I think that bubble could go back and finish.

They could.

They kind of have left it, I'd say 75% there. I mean, they could make tables better there. There are things they could figure out and make better.

But, but the main reason why I brought this up is because tables are 100% more mobile, mobile friendly than repeating groups. They're easier to maintain repeat, they're easier to just make them horizontally scroll when you're on a smartphone. So it's just gonna make your life a whole lot easier. But yeah, I agree there's a few things here and there that bubble could still.

Oh, yeah. I mean, it would be nice to be able to sort by columns, you know, inside the. Inside the table. Right. Without having to, you know, program it or, you know, do the pagination natively instead of building it into your workflows. But hey, those are just workarounds.

And the last obstacle that we wanted to talk about is maintaining your bubble application over time. And this, this obstacle is really just for us to give you some tips on how to make your life easier. For example, the first thing that we wanted to mention is you have to start. You really have to start using reusable elements.

Yeah, that's my second thing I look at when I. Somebody asked me to look into the.

How many reusable elements do they have?

Yeah. And when you go in and see the backend workflows are empty, or pretty much empty, and the reusable elements are.

Not there, or there's only two of.

Them, like header and footer. Yeah, something like that. Then you start thinking, we need to give this customer a little bit more education. Because reusable elements are lifesavers.

Why?

Because they allow you to build something once and use it wherever you want without having to copy paste. You save time, you save a lot of time. And it really shows up in the maintenance.

Part of your, of the lifecycle of your bubble application. You can get away with not using them when you're starting out and that will get out of hand and you'll come back and you'll say, oh, I should have done this as a reusable. I should have done this as a reusable. I should have had a reusable inside this reusable to make my life easier. If you structure things well at the beginning, you don't have to do all that work in the, you know, down, down the road. So, you know, that's a good example of how a little bit of planification can.

We've already talked about this one earlier, but moving as many of your front end workflows into backend workflows is also a really good idea.

Yeah, I think we talked about that. But it's also a good idea to.

Really start thinking about what elements in your bubble application.

Are used multiple times, because that's where you need to put the focus. Because there's nothing more boring and more.

Frustrating than having to fix a bug 17 times because you have it, you know, it's. You found it in one place and now you've got to go fix it in all the other places that use the same idea or the same workflow but aren't interreusable. That is grunt work that nobody wants to do. And it's also opening the door towards.

Things falling through the cracks. You forget, you know, if you've got something copied 15 times and you fix it 14, well, that 15th time could be. Is the one that's going to come back and bite you in the ass. You know it's going to happen and you know it's not easy. I mean, you know, bubble, at least it has the little, you know, looking glass thing to, to, to find, you know, every time you use a field or something.

But, you know, now, when we were planning for this podcast episode, Dennis included this item here under obstacle number five, which is to make your menu items or, you know, your menus to stop hard coding them and instead have them power. Have them be powered by option sets. Why, why did you throw that in there?

From personal frustration. That is one of the things that gets makes maintaining an application.

Un unenticing is that you have to go and make a change in a menu, something as silly as that. And then you have to remember, oh, but I've got to change it in the mobile menu and then I've got to go change it on this secondary header that uses a different color scheme and then I've got to go change it and. And then you say, oh gosh, just because I wanted to change one text in the in a menu or add.

In one menu item or add in.

One menu item or you got to.

Go to 25 different places or change.

The icon for a menu item and now I've got to go 20 different places and change it. That's just kind of not convenient. It's not convenient at all. And by one of the cool things about option sets is that they are really fast. They're not using the database and so they're a good. It's a good example of how you can save some. Some time and headache.

You are a big fan of greeting. You like to call it the special reusable element where you essentially just drop in there. A bunch of different custom events. Yeah.

Why? Well, I already talked to you about. I love custom events. They're great for making sure things happen in order and all of that. And don't think about reusable elements as only visual things on your page.

Your business logic is also reusable. So if you have a custom event that calculates the total of an invoice and you may need to use that on five or six different pages. Well, don't by, you know, don't copy that custom event from one page to the other. Put it into a reusable element that only has custom events in it. And then there's a really cool feature in Bubble which is trigger a custom event from a reusable element. And so now you can just take this like having your own little toolkit. You can just take it from page to page and use the ones that you need and It'll save you just a boatload of time.

So I think that wraps up the probably most common obstacles that people come across when they're trying to build something with bubble. A lot of the things that we've talked about in today's episode we've addressed in how to videos or many videos that we post posted on our YouTube channel. Again, you don't have to go through the gazillion different videos that are on our YouTube channel. You can just go to our resource center. It's completely free and you're going to see them properly listed in a really nice way for you to clearly identify. Okay, I need help with understanding custom events. It's going to be clearly labeled and you can just click on. That link will take you to the proper video where you can learn about that specific topic. It's linked down in the show notes below. I think this was an interesting episode.

Yeah, I think it was. I hope that it will help people on their bubble journeys, you know, get there faster and have a better application. And when you call and you say, hey, I want you to look at my bubble application, I don't have to smile at your lack of reusable elements or backend workflows. I can see that you're doing a good job and I will congratulate you that on that on our next call.

Awesome. Well, thank you once again for another week.

Talk to you guys soon and we'll.

Catch you guys soon. Bye.