My biggest performance killer was that I had another Reusable Element(B) as popup in a Reusable Element (A). This popup was quite complex. Reusable A was again in a repeating group. This is clearly the killer number one.
After fixing this problem my page loading time went down from 60 seconds to less than 10 seconds and there were only few results in the repeating group.
For me the worst thing for the UX is/was displaying relational things even if with small number of things on the list (less then 10).
e.g. I wanted to display list of Things2 in the RG
'Current user List of Things1:filtered List of Things2`- this was super slow
The best thing for me was just creating field type List of Things2 on the User data type even if it doesn’t make sense when it comes to DB organization.
Also pretty heavy operation for Bubble was to setting the source for multidropdown as Search for things. I made the effort to move over 500 items to Option sets and its lovely now.
++ I almost never use Searches. Everything is organized with relation to Current User. But that of course it depends on the app.
Interested to hear more about this one, since I’ve moved to organising a lot of my apps in reusable elements (makes programming much easier). How was your app set up so that it killed the performance?
When you say ‘Do a search’ slows down your app performance it is quite confusing. Isn’t that how typical databases work? Normally if your search criteria is quite specific, then it should improve performance instead. I see a lot of advice on how we should put a lot of information on the user table so as to increase performance. I think the technical team should be working day and night on this because great apps should be able to manage simple one-to-many, many-to-one relationships without causing too much performance issues.
For searches in the “do a search for” box, Bubble finds the results very fast. If the search is slow, it’s usually due to download times – like if you are returning a large number of records, and/or the records are very data heavy.
Advanced filters (required for many-to-many searches) can be slow because those are done client side. But one-to-many searches can be handled by Bubble server side via the regular do a search for box.
Re: whether it make sense to use a list field to replace a search, you generally want to avoid long lists in the list field.
Nice discussion on this topic in this mega thread:
The best approaches and some good insights into the inner workings of Bubble are also well outlined in this ebook: