How can I make my Bubble app run faster and work more smoothly?
Its depend on lot of thing, but one adice i give give is , Be Lazy … Try to find ways of minimizing the work and with less element.
Hi suheb!
You should try putting set state when fetching data instead of do search for. Setting state means you are loading the data Once which means it lessen the workload of your browser, while do search for is fetching new data in the back end constantly.
I hope this helps!
1 Like
@suheb.devtechnosys this is a very broad topic (enough for me to write a whole book about it), so it’s hard to give advice without more context. Very simplified, the more your app does, the slower it gets. This is true for any framework. But of course, what it does relies on many things:
- Workflows
- Database queries (number, size and complexity)
- Code size (number of elements, workflows, etc on each page)
- Download size (data, images, fonts, plugin libraries, etc)
In a sense, intuitively keeping your app lightweight will make it faster. But of course, that all sounds good but it’s not a very detailed blueprint. If your provide some more context (for example point out specific processes in your app that you find slow, such as page load, a given workflow, etc) it’ll be easier to give more pointed advice.
Regarding @cyrel.hurboda’s suggestion, I don’t mean to sound dismissive, but this is not a practice that I would recommend unless you’re aware of its implications. It’s true that setting a state with a search result gives you a degree of control of when and how often a query is performed, but it also means you’ll be left with a static list that depends on a workflow to update. One of Bubble’s strengths is that any search query is automatically updated as soon as something changes in the database, and in most cases you’ll want to keep that connection open.
4 Likes
Trying to use less elements is a bait, don’t fall for it.
For Chromium Browsers you can use Googles prerender script.
Example:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["/version-test/page-name", "/version-test/name-of-another-page/"]
}
]
}
</script>
1 Like
First of all, I believe it’s the Database Design, because the way we load data directly impacts the speed of our apps. After that, as our colleagues mentioned, simplicity, trying to minimize things is excellent. We should always think in terms of a reusable and simple structure.
There was another topic I commented on as well, and there are other interesting comments there:
1 Like
This has helped me too! Someone else in the thread points out that it does depend on whether or not you need the data to refresh, but if static data isn’t a problem, then this is a big help.
1 Like
I recently learned that when setting a data source, it’s much faster to have constraints in your “search for” rather than filtering.
Backend workflows are faster than regular workflows.
Both things basically move the processing closer to the database, which happens faster and more reliably than processing client side (or at least that’s what ChatGPT tells me).
Not to disregard that you helped write the new Bubble docs but you make it sound like it’s a bad practice when it’s not. It’s a technical choice.
Not every list needs to be updated realtime. A lot of inexperienced users fall into the trap of planting searches as data sources everywhere. Only to end up wondering why their WU blew up as they start to get more users.
OP: It’s important to learn to map out the user’s journey/experience in each page of your app. Then you can design your workflows to ensure performance and a good user experience.
In Bubble, loading data tends to be the biggest culprit that bogs down performance. A common problem is having large searches happening in parallel.
You can either:
- serialize your searches
- ensure data loads only when the user needs it
Here are a some ways to go about it:
- if you don’t need a search result to be updated in realtime, store them in states. Let the user decide if more results should be loaded
- only show elements that have large searches when the user needs it. Learn the nuances of hidden elements in the manual.
- use workflows, states and conditionals to delay element loading and workflows. You can store workflows in a custom event then schedule instead of run.
Other important things to note are
-
on page loadevents also trigger everytime you navigate the user to update the current page’s URL parameters. Store workflows that should only run once on a page load in a custom event that checks some kind of “first load completed” boolean state. -
Use search constraints. Avoid using complex advanced filters or nested searches.
-
Well structured databases play an important role in performance. This includes using privacy rules. Good DB architecture also enables you to define more precise search constraints.
Optimization has layers — User Experience and Cost.
Always put the user experience first, even if that means spending more. Whether through higher workload units (WUs) or extra tech stacking.
By understanding which parts of your design and workflows drive cost, you can make smarter, more intentional engineering decisions in Bubble.
2 Likes
Small tip: If you notice you are doing the same thing over and over again, don’t do it. Do it only once and reference it. 
1 Like
this^^^ custom events
1 Like
It’s a technical choice.
Exactly, that’s why I said unless you’re aware of its implications.
As an informed design decision it’s perfectly fine, but moving your searches into workflows as a blanket best practice to improve your app’s performance without understanding how it works is not something I’d recommend. And as you say, new users tend to follow the advice they get, sometimes blindly.
I agree with your overall point that new users tend to use searches uncritically and place them all over the place on page load, and it makes sense to be aware of that, but still think using states is a piece of advice that needed some clarification and nuance.
I also very much agree with your point on user experience – it’s an important reminder, especially when discussing performance.
3 Likes