Repeating Group Load Time & Background Loading?

Hey guys,

In my app a repeating group takes 3-5 seconds to load 100 rows of content - increasing the page bounce rate.

To get around this I’m currently limiting the app to show the first 15 rows on load and then allowing the user to ‘Load More’ by clicking a button and showing the 100+ rows.

I wondered whether it would be possible to get the app to background load the full table or load cells only on view (similar to when infinite scrolling is enabled in a repeating group).

Any tips/ suggestions really appreciated.

App link for reference -

Kind regards,

Can you use infinite scrolling for the rep group? So that it starts with 10 or 20 and loads more as the user scrolls?

100 entries is not nothing, at the end of the day, it takes time to load things. Facebook for instance won’t load 100 posts at once, it’d be too slow.

1 Like

In addition, I would also have a look at your data and what you are searching / sorting on.

It is very unscientific, but I end up de-normalising sort fields so they are in the main data type and a primary field, the aim is to avoid relationships and counts.

I’m having the same problem here. Many of us in this forum have mentioned that we want to build a chat function. In order to do this, we’re forced to load the repeating group and focus on the most recent entry. Unfortunately, this means that everything has to load in order for the most recent chat to be seen.

Right now, the focus doesn’t go to the last item when the repeating group has more than 100 entries.

Given that my company is chat based, it may end up being a make-or-break for whether we can continue with Bubble. Are there plans to fix this?


@maryfox20 - any update on this front?

@emmanuel - how much would it cost to sponsor a repeating group that loads “upside down” (Like a typical messenger app: From the bottom up.)? I would imagine this could fix the issue. That way, if they wanted to scroll up to load previous messages, they could, but it would load the most recent message lighting fast.


1 Like

I’m not Emmanuel but you’ll need to email [email protected] for a feature sponsorship.

1 Like

Ok - will do. Thanks

@richardsonjj36 you can already emulate that with a scroll to action.

Here is an example made based on a popular Udemy course (not my course, not an affiliate link, just a great course):


It’s a workaround, but it works :slight_smile:

@Lucien Thanks for sharing your example! I’m working on something similar–a texting app–and the simplicity of your approach was very helpful in many ways.

Quick question if you don’t mind? No rush on this, whenever you have a chance. Apologies in advance for hijacking this thread.

Can you explain the scrollbar html header? i don’t know html/css. I see the two webkit-scrollbar entries. Just wondering what each does/why each is required.

I’ve read many discussions here on hiding scrollbars. Your solution is the best I’ve seen!

No problem. Full credit to Salar Ali from @copilot :slight_smile:

For the HTML header, it’s just a cosmetic addition. You don’t need it (but you might want it). The purpose is to hide the scrollbar of the repeating group that can appear with some browsers (or when you’re in incognito mode on Chrome apparently).

Without scrollbar:

With scrollbar (removing the HTML header and visiting the site on Chrome with incognito mode on):

I found that small piece of magic :mage: code somewhere on the forum but I can’t remember which thread. Some variations of it allow you to control the style of the scrollbar if you prefer.

@Lucien – Thanks! Your solution is awesome and does help a lot… although have you noticed that when the repeating group contains lots of messages (more than 20-30 or so), it struggles to load & scroll quickly? Just doesn’t feel like a crisp messaging app. Feels a bit clunky. Maybe it’s just that I need to purchase more server capacity, not sure. Will test that.

1 Like

Thanks for the message. We did this a long time ago and that’s what we’re currently working with - but it’s too slow.

1 Like

Hi, has this been fixed? I think we still have to work with the “scroll to” last entry - but surely not crisp and the user experience is not great as it “struggles” to lead everything if the chat is big…