I’m stuck in a performance issue when loading the page for the first time.
I have a SPA running with the following structure :
1 reusable with loading logics to set view and check permissions
1 reusable with the menu
20 hidden reusables used as different views of the app, each includes multiple reusables such as list, item display and form (new/edit). In some cases, item includes form (new/edit) in a popup.
The SPA used to take 3 to 5 seconds to load the first page.
Since a month or so, the SPA starts to take 10 to 45 seconds to load the first page, very unstable.
The navigation between reusables is still working fine.
I tried to figure out the problem by
deleting the custom domain, creating again with new IP for dns
placing all reusable data source under conditions
placing all RG data source under conditions
removing some groups that were just easy to read in bubble, but not necessary in the app
The loading time of the first page went back to 10 seconds, very stable.
I can’t go below 10 seconds and I don’t know where to look at. Is there a custom JS stuck, an infinite loop between 2 reusables, a bad condition hidden somewhere, I don’t know.
The current display is the following
The page is first blank during 8-10 seconds
Then first log prints in the console
And the page starts rendering elements in less than 3 seconds
I wish to remove that blank moment where the user thinks the app does not work.
Here are couple of screenshots in case you see something.
Any idea to where I need to search ?
The Bubble plan and your location do have an influence, but what weighs the most in SPAs is what loads at the beginning: images, too many plugins, workflows triggered on “Page is loaded”, searches without conditions, and many preloaded views.
Be very careful with searches that run before anything is displayed; create conditions so they only run at the right moment.
Check whether you have many “Page is loaded” and “Do when condition is true” workflows.
Also review what is initially visible to the user.
Good “Styles” practices in your groups, buttons, text, and inputs also help.
From what you mentioned, I see may be 2 problems :
We use fuzzy search. The data source needs to be set. So we added condition to hide the element.
That could be a problem?
When we have a reusable item (1) with a reusable form (2) in a popup, we always have a custom state in (2). This custom state is cs_hide y/n. In the reusable item (1), we do have a “Do when condition is true” for cs_hide = yes in order to hider the popup.
That reusable item (1) is often in a RG.
That could be an issue or not at all?
What do you mean by good “Styles” practices in your groups?
Hi @emir.ozgun
They are all used.
The only one I can remove is copy content to replace with a custom JS.
For the rest, I would need an alternative if the plugin is not good.
Even when using fuzzy search, you should create a condition on the data source so that the search only runs when it’s actually needed. Simply hiding the element does not prevent Bubble from executing the search, so this can indeed impact loading.
Regarding the popup, I would recommend keeping it outside the reusable. You can trigger the popup and pass the selected item’s data using custom states on the page (or Toolbox, if you prefer). This way, you avoid having Do when condition is true inside a repeating group, which usually doesn’t scale well and ends up hurting performance.
I also wouldn’t say that these two are necessarily the biggest problems. I think there’s more to investigate—there’s definitely something you haven’t seen yet—but if you dig carefully, a small detail can significantly improve performance.
I would also recommend trying to uninstall some plugins. In SPAs, all plugins are loaded at startup, so having many of them can weigh down the initial load. Several of these can be replaced by Toolbox itself, such as base64, copy content, and JSON manipulation.
I don’t know exactly how your app is built, so I can’t say precisely which plugins to remove, but usually, when you review things calmly, you can always eliminate a few.
Also, I noticed you’re using the Audio Recorder Pausable from Knowcode, which is a paid plugin. You don’t need that you can use mine instead—it’s fully customized, lightweight, and free:
I wasn’t even talking about Option Sets themselves.
But actually about “Styles” specifically.
Having good CSS can indeed help with your app’s performance. If you have three buttons with the same style, but that style isn’t defined — meaning it’s set as “None (Custom)” or “Overridden” — you end up increasing your CSS stylesheet more and more, and over time this also impacts your performance.
you can use mine instead—it’s fully customized, lightweight, and free: