Performance questions - page loads quickly but then freezes

[david.j.hansford]

We’ve recently run into some serious performance issues when a user loads our website in their browser. The page loads quite quickly but then crashes the browser (I’m using Brave/Chrome) after loading. If you select “wait” when the browser says the site isn’t responding it will eventually unfreeze but quickly freezes again from as little as moving the mouse across the screen. Is it possible to get some insight into how bubble renders our pages so that we can identify what is causing the issues and resolve it?

As an overview, we have a quickly growing database of our customers’ Slack messages. Currently we have about 25k but are onboarding new customers each week and pulling more Slack messages from existing customers through their API constantly. Our site is split into two parts: a dashboard and a library view. (There’s a homepage too but that has no issues). The dashboard and library are built as single pages with different views that can be loaded within them. The library has the worst performance issues currently. It has a repeating group that loads 15 posts (the results are paginated and filtered by Team, Category and a few yes/no flags, also privacy options limit a User to seeing only their own Team’s Posts). Each post in the RG loads data from one data type (Post) except the image which is currently found by doing Post > Post_expanded > Slack_user (no searches, each is directly linked together). Would it help to keep a copy of the user’s image URL in every instance of a Post?

Also the members page in the Library and the Dashboard crashes too. We have 6.8k Slack_users in total and we display all users from the User’s team (typically ~300-1000 currently) in a RG paginated to 20 instances.

I’ve been reading through some great threads in the forum and have some things to try but if someone here can give us specific advice for our situation that would really help! Our current thoughts are:

• remove all ‘do a search for’ that we can (already done this in the library with little improvement)
• move everything possible from a fronted WF to a backend WF (most things are already in backend)
• reduce the number of elements on a page
• remove unused plugins

Couple of quick starter questions:

1. Is finding something in the database through direct links such as Post > Post_expanded > Slack_user quick? Is there a better way to do it that doesn’t involve replicating data in the Post to avoid finding it elsewhere?
2. Does it make a big difference to performance if the Post data type is as lean as possible? We just created Post_expanded to hold all Post data that isn’t needed to create front end views. Was that sensible? (It didn’t appear to make any difference to our performance.) Should we do the same with Slack_user?
3. What could make a site freeze in the browser after loading all the elements without clicking on anything?

I’m aware that I probably need to give more details so please ask and I’ll happily provide anything needed to better understand our situation.

[josh24]

Here’s a couple of suggestions:

1. Run your page with the debug mode turned on and have it set to step-by-step. This should give you a good idea if there are any workflows that aren’t performing well that you need to take a look at. This is hopefully going to unearth the freezing that you’re experiencing.

2. Think about adding a popup to your page called Hidden variables and for any data searches you reference more than once, consider whether you want to load them into a group on the popup and then reference that. This can cut down the number of database connections you need to make. You might also like to think about how you can slice up some of your heavy searches using this tactic as well.

3. Make sure you aren’t using any commands in your search that manipulate the data in the browser, such as :filtered

4. Splitting up the data as you suggest in #1&#2 makes sense

---

Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand

I post daily about no-code and Bubble on Twitter

[david.j.hansford]

Thanks Josh. We worked out that the main issue was a plugin (zeroqode’s fuzzy search), after removing it our site performs well. That said, we’ve made a lot of other performance improvements alongside this, including some of your suggestions.