Pagination performance benefits

Does a repeating group pagination speed things up?

With filtered data:

Is bubble only pulling the required data to fill the current page or is it pulling all the data? It seems like it pulls all the data when I look at the network tab in chrome.

If that is the case maybe its saving on client side filtering, as in only filtering the data that’s needed for that page?

Or have I got this all completely wrong?


Hi @kpm,

Yep, you’re correct. Bubble loads all the data upon change load, but I believe pagination helps speed up the displaying of data (anyone correct me if I’m wrong :sweat_smile:)

For example, if you were trying to load 5 items on the page vs 100, 5 items would be faster

Thanks Johnny.

That does make sense… Not having to render all the items on the page.

Just curious how client side filtering behaves with pagination.

If you pull 500 records from the server and client side filtering narrows it down to 100. I wonder if each page has 10 items, would client side filtering all happen at once or partially.

Pagination is a must if you’re dealing with >100 records and // or dealing with >10 records in a repeating group that has complex data like videos and images.

I would strongly suggest checking out Listshifter by @keith . It comes bundled with his Floppy Plugin

Makes pagination a breeze. Bubble default pagination isn’t exactly dynamic.

Bear in mind only Advanced filters run on the client. Other filters run on the server.

But yes, client side filters run on all of the data. Else, how would it know what to display first? :slight_smile:

Actually, not only Advanced filtering is carried out client-side. There are some cases when the part that should be :filtered is too complex for Bubble to merge in 1 DB query. And in these cases even basic filter will be applied client-side. I haven’t faced such cases in my apps, but this is the info I got from Bubble support :slight_smile:

1 Like


I will look into the listshifter plugin.

I’m trying to avoid a “Intersects with” advanced filter, so looking at any alternatives.

Makes sense. Thanks.

Are you saying that Bubble support indicated that some search constraints are too complicated and so those constraints are filtered client side? What I mean there, is when filtering is done properly, the ‘filters’ are constraints put onto the Do a Search for, which all of those constraints/filters are done server side.

The only time a filter is done client side is if after the Do a Search for expression you then use the :filtered operator, and in that case, in which you use the :filtered operator, it is not just some that might happen client side, it is all that happen client side.

Has Bubble support indicated something different?

You can have a hidden repeating group to hold your search results from the DB, or a custom state, or use a Paid plugin like listshifter to hold onto the original search results from the DB.

Then in your RG that displays the results and incorporates pagination, you don’t use a :filtered operator, you use the :items from and :items until operators (note, this is in the event you do not use the Paid plugin ListShifter, which does actually make things easier, as the plugin has the ability to set the number of items to be displayed per page and has functions to go to next page etc.)

In my apps I use the ListShifter plugin. The more items you show on the page the longer the load…typically use pagination in such a way you use divisible by 1/2/3/4 for numbers are 12/24/36/48 etc.

In my apps I set the default value of items per page to 12, then give a dropdown to users to select the number of items per page to display in 12/24/48/96 increments, and when a user makes a change to go from 12 to 96, it is pretty snappy and the 96 items are visible almost immediately.

Hey @boston85719 we have a marketplace app that has > 500 products. Currently, we’re only using lazy loading and filtering them using daisy chain filters. We’re keen on adding pagination but so far have only agreed on creating a vanilla bubble pagination feature.

I’ve heard so much about @keith’s list shifter / floppy and I think it’s about time to ride the hype train.

Also, how much of a difference will it produce WU-wise if we were to use vanilla pagination compared to using list shifter pagination? Will it save a considerable amount of WU?

Would you be so kind to point me to the right direction on how to create a pagination feature using list shifter / floppy? I’m aware that keith’s plugin can amazingly do LOTS OF THINGS but we’re only aiming to implement the pagination feature for now. Will learn more about the other functionalities in the coming weeks or month.

Would greatly appreciate your help :pray:

Should just filter via the constraints, so much easier and better

No idea, but I look forward to you posting the results of the tests that you will run to find this out

1 Like

I find daisy chain filtering much faster compared to constraints. Plus, I can easily stack filters.

Got it. Will comment on this thread again as soon as I get the data

Should just filter via the constrains, so much easier and better

This definitely depends on the usecase. For a simple static search, sure. For allowing users to select filters and then to stack all of those filters on top of one another dynamically, daisy chain is the way to go.


I can’t imagine how…have you tested this with a speed test using the computer and not just naked eye test?

Basically to set up a filter, it is always going to be faster via the Server, which if you put your constraints directly onto the Do a Search, will happen via the Server.

Additionally, you can use the little checkbox at the bottom of the search constraints to ignore empty constraints, so no worries at all about allowing the user to select filters and have those selected filters alter the search results immediately.

Plus, no need to run workflow actions to filter. I’m honestly not 100% sure how you guys have these set up but my assumption is there is either a new search performed on each workflow that is part of the daisy chain, or you are passing the values of one filter to another workflow action that uses the :filtered operator (which is done client side and slower than server side).

Lastly, so much easier to maintain and fix or implement new filters via the constraints as you don’t need to try and find a way to fit a new workflow action into the daisy chain, and instead just add a new constraint to the Do a Search.

I’m honestly very interested to hear how daisy chain is potentially faster than normal search constraints, or how daisy chain is easier for doing searches with filters the user selects. Always open to new ideas and improving the way I develop.

I always have a button called „show more“ with a custom state value type number and the starting value: 20

Then repeating group source: do a search for #items until buttons custom state value.

When clicking on this button I add 20 to the value until the repeating groups count >= do a search count.

So you have a lazy loading and can decide how many entries should be displayed at once and per click.

Works perfect for me, almost no loading times.

1 Like

Keith isn’t known as “America’s Most Loved Bubbler” for no reason. ListShifter is scary good…and i’m a crappy programmer.

I would also strongly suggest looking into Scious Search. It’s a plugin that allows you to use server-side searching from typesense or algolia.

I would contact @zelus_pudding about getting access to the beta. It takes a bit of code to set up, but once it’s done, it’s literally like black magic. Scious + ListShifter are my fastest plugins by far.

If this marketplace scales into the thousands and more, I would strongly consider implementing scious.

Also, because it’s using server-side searching, it improved my app performance // battery life tenfold. Your browser doesn’t have to do much.

1 Like