Quick question on data load optimization in RG

Hey guys,

sorry about the cliche topic but I couldn’t find straight answer.

I’m doing small pivot with my app and I need to create search page that will search for users with certain skills, experience category etc.

Now as this wasn’t the plan from the beginning I wasn’t optimizing the User datatype for a search. It has over 50 field type, some are simple boolean some are much more complex. A lot of data.

I am thinking about creating simple “mirror” datatype that I would call UserMirror that would only have: profile image, description, category experience, rate, list of skills, link to user profile on it - which is what I need to display results into RG if the user want’s to see the full profile I just redirect him (in the new tab) into the /profile page .I plan to have at least 500 users with profiles and seeing the bubble logs with only me loading 9 profiles … is scary (rg is set to ext. vertical scroll not full list)

This thread got me thinking about the amount of data I am loading even if the data is not displayed on the page. Thank you @lottemint.md

I am sure some Bubble ninja has already spoke about it but I can’t find the right topic :frowning:

any thoughts/advice? Is it good idea?

shameless strategic bump :smile:

anybody? I think I will go for it

I went back and read the post you referenced. Posts about speed and optimization usually focus on which way to connect data and related pros/cons. This post however brings up a new angle – how and whether the number of fields in a datatype impacts search and load performance.

Let’s say there are two datatypes – datatype More and datatype Less. Each contains the same number of things. Datatype Less has 5 fields. Datatype More contains 50 fields.

Then you set up searches for Less and More which are executed server side. The searches are exactly the same (the searches for More and Less only use the fields that are common between More and Less). Is the time and utilization on the server side the same for these two searches? Or does More take more time and utilization because it has more fields, even though those extra fields aren’t being searched?

Then you display the search results for each – say it’s around 25 things. You set up the RG so that it only displays the Name field, and nothing else. Is the time and utilization to display the list of names for More greater (because perhaps it is loading all the fields into the page, even though only the name field is being displayed)? If so, is that difference material?

I think the question is not only if there is a difference, but how material that difference may be.

Hey @ed727,

thank for the input. Yes, what you wrote is much better articulated dilemma I have.

I did some more digging

I did the same test NigelG did. Load the visible data, drop the internet connection and display the data.

test it here

I think UserMirror is a good move - but there is also the next action which is using the link I have in the RG and sending the data to the next page - and what kind of impact will that have on optimizing the page load of the next page.

image

1 Like

Ya the UserMirror idea is a good move.

@lottemint.md is correct in his strategy.

For your example, if you create UserMirror - and load all of those items in a repeating group, you will link to your user via one-to-many relationship. Only the unique ID of the user will be loaded into the browser (not all 50 fields of the user object).

Keep in mind an alternative perspective as well though. If you offered pagination, and only loaded 10 users per page; you may not need to do this UserMirror database change.

As for linking to the next page, I would not worry about that, until you witness or hear of performance issues. Which you probably wont. The main concern here is the repeating group, if you are loading 100s of users in an extendable (one page) repeating group and each user has 50 fields (and you haven’t implemented the UserMirror stragegy - you will eventually have a very heavy page. May compromise user experience.

1 Like

Actually , I should clarify. I don’t think the pagination would help for this one.

With 50 fields per user, even a 3 celled repeating group might take a long time to render right on page load (im not sure); but as you say, you have seen in your logs, it is a heavy resource.
Definitely advisible to break it up into different tables userMirror style.

Thanks, it seems that every time I turn around I learn something new about performance optimization.

Question though – if you’re going to mirror your data, why wouldn’t you display the detail version in a popup or hidden group, on the same page? Going to a new page seems like it would take more time/resource.

hey @jordanfaucet!

Thanks for taking the time. I should say that your posts in the thread above were as influential :slight_smile:

Yes I do plan to use extendable repeating group rather than pagination. I think its better for my case and UX.

I’m thinking that too. I will be sending Parent group UserMirror’s User so should be the same it terms of page load speed

1 Like

same here :slight_smile:

  1. In my case it looks like an industry/product practice. Opening the user in separate tab. I think people search by certain keywords open couple of profile in new tabs and then compare them. The hypothesis here is that is better for UX (will test that|)
  2. I was considering popups and then having the ability to open a profile in the new tab (or straight from the search having a small icon) but I have done that in the past and having a lot of data loaded into the popup wasn’t so great because of: a) time to load the data/lags with display the popup itself b) data loaded previously was visible for a sec ( I could reset the groups when the popup is not visible etc but still)
1 Like