Building an advanced range filter but loading is slow

Hi all,

I have a problem that I hope the forum here can give me some ideas on how to solve.

I run an investment app that helps user find the right investment funds. Right now I have around 130 funds on the platform.

Recently, we’ve implemented a sets of four advance filters that let user find a list of funds based on four criteria ranges (see figure below):

The four advance filters that

The user experience I want to give is as the user changes the range of the various filters, the list of funds will automatically get filtered out.

However, I am now running into a problem. For the filter the work, the data of the funds have to be all loaded. With over 130 funds, I have over 2,000 data points that need to be loaded in order for the filter to work and that has created a very long load time of nearly 60 seconds.

We tried using a loader to indicate the filter is not ready but that clearly takes away the user experience as you can see from the video:

So I wanted to see if anyone in this forum can:

  1. Suggest ways (either by native Bubble app or third party plugin) that can speed up the load time, and/or

  2. Suggest a design that would make the loading more transparent to the users.

Any help on this matter is greatly appreciated.


If you mean you are using the advanced filter then that is why. It loads all data into the user’s browser before the advanced filter can be used, so imagine whatever search you are doing before that and all the huge number of results (the entire database?)

I suggest restructuring so those number fields are pre-calculated on each thing (if possible, maybe maintained with database triggers) then you can use regular search constraints for lightning fast search results

regular search constraints will work if like @tylerboodman mentioned you put the values in fields on the data type.

Have a field like Min and another like Max, both of which would be of type number

On the regular search constraint you can reference the same value in more than one constraint…so you are using the element type of slider, which provides for a min and a max value from the one element.

In your search constraints you will have a constraint for your Min field (the one you add onto your data type) with an operator of greater than or equal to the sliders Min value. Then you do the same for Max field with an operator of less than or equal to the slider Max value.

1 Like

Thanks @tylerboodman and @boston85719

But I’m not sure I understand what you mean.

The underlying data are pre-calculated. For example we have four filters…

  1. Annualised Return Since Inception
  2. Annualised Standard Deviation Since Inception
  3. Upside Volatility
  4. Downside Volatility

Each of these is a data field on a data table for each fund.

Are you saying I need to create two additional field of reach like

  1. Min Annualised Return Since Inception and MAX Annualised Return Since Inception?
  2. MIN Annualised Standard Deviation Since Inception / MAX Annuslised Standard Deviation Since Inception?

And so on…

And then have the search reference those data field instead?

Okay, so each data entry has a single field for these 4 metrics, as a simple number or percentage which is fine.

Not if you have just a single value field already…I was under the impression you had a single field of number range and not a number

So, take those existing fields and use them twice in the constraints.


Annualized Return Since Inception is greater than or equal to slider Min Value
Annualized Return Since Inception is less than or equal to Slider Max Value

Also screenshot your actual data source and what your searches/constraints/filters look like too. Using search constraints is different from adding :filtered to the end of a search

Here is the screen shot of the data source. This is for one single fund and the red frame are the four data fields which the filters are built on.

Below is the search constraints that are applied to the slider

Yea that is your problem. What are you constraints directly on your search? (Not the filter after the search)

Those look like they can easily be individual search constraints just stacked ontop of each other. Those are performed serverside during the search process so they are very quick.

Right now you have a filter clientside so its probably downloading the entire database then filtering after :joy:


Thats terrifying :joy:

As @tylerboodman and @boston85719 said, put the constraints directly on the search. You’ll see huge performance increadses, as well as big WU consumption reductions, as right now youre downloding huge amounts of data unnecessarily


Question: If I put the constraints directly on the search, would it still create the visual effect where as I change the slider, the search results appears?

Like the screen shot below?

Yes :+1: