Forum Academy Marketplace Showcase Pricing Features

Improve Data Load Speed on Hidden Elements

I have added a new video demonstrating a technique I use to improve the speed at which data on hidden elements is displayed when the hidden element is made visible for the first time.

It makes use of an extraordinarily powerful Karmaware plugin.

Video Link


Do tell.

Come on, Keith, admit it… you paid him to do that List Shifter commercial, right?

No offense at all to the creator of “the most underused plugin on the Bubble marketplace,” but isn’t it overkill to use List Shifter in this case? I mean, wouldn’t setting a custom state on page load do the same thing? It kind of feels like you need to hang a picture, and you pulled your sledgehammer out to do the job. Sure, it’ll do it, but the sledgehammer is thinking, “Wait, really? This is all you wanted me to do?”

Also, do you find that preloading everything has an effect on the initial page load? You know, maybe a robbing Peter to pay Paul kind of thing? I could be way off on this stuff, and maybe I just don’t understand the exact benefits of what you are doing and how you have chosen to do it, but I am legitimately curious. I mean, I did actually watch the video… twice. :slight_smile:

1 Like

It is actually just a tip to help people build better apps.

No, because that would require a workflow. And if the data changes would require another workflow to reset it, but there would be no real way of knowing if the data in the database changed in order to reset the custom state without having more workflows etc. And custom states do not come with the benefit of using other list shifter functions like pagination if you need to.

That would be the same issue when using custom states on page load. And in this case as it is a page for a profile, it is not loading the entire database or anything like that, so pretty quick initial page load.

Give it another watch with audio and the explanation of the purpose, which is to avoid the lag time between when the element becomes visible and the data is loaded into it. Makes for a better app if the data is available and visible immediately rather than a 1/2 second lag since the alternative method of using the search on the element only happens when the element is made visible.

Everybody will have different methods of building apps. I use this method as the over 4 years of experience building apps as led me to find this a good method. You’d be surprised at the kind of stuff some of the larger agencies do, like having a popup on every page that has ‘variable elements’ preloading all data from the database.

If my client asks me to fix a perceived issue, like this case of a lag time between when the elements are visible and the data is made visible, I will find a way to fix it. I always appreciate when my clients push me to find new ways of doing things.

You do know the commercial thing was a joke, right? :slight_smile:

Thanks for the detailed breakdown, Boston… much appreciated. Oh, and I did watch the video with audio, of course, and the purpose could not have been more clear.

You are definitely right about everybody having different methods of building apps. In my opinion, that’s one of the biggest blessings and curses of Bubble… there is never just one way to do something, and there usually (but arguably) isn’t one “right” or “best” way to do something. In the end, if it works, it works, eh?

Thanks again, man.

Yes. I just don’t have the text based social skills to use emojis to represent my emotion behind the response. I should maybe get better at it. :woman_shrugging: :point_left: is that the correct one :confused:

I have to tell my students this all the time. They seem to get frustrated when I ask as many questions as I need answers to in order to provide them the approach I personally find best for their use case. I am always needing to express that for some situations you may find one of the handful of ways to be a bit better, and in others situations you’d find one of the other approaches more appropriate.

Definitely love the fact that Bubble doesn’t tie our hands together and allows us to make our own mistakes and discoveries.

BTW, I use a similar approach to loading the lists when I am working on filters of different types. An example is I had to upgrade a CMS template to the new responsive engine. I took the time to optimize it, and one of the things I did was to have a list shifter search for the posts, and then in a single RG datasource (which changes conditionally), filter the list shifter list using the :filtered operator so user can view between post author, post category or post date. Works so much faster compared to when I had a search on 3 RGs with the constraints to constrain by author, post category or post date, and reduces the amount of times I need to touch the database reducing the capacity the app uses. In that I also would be making use of the listshifter pagination functions.


Awesome @boston85719 ! Thank you for this tip!

I had this doubt too, what Bubble is trying to do (recent performance update) is to show elements only when they are requested.

This way we are loading everything in page load, UX undoubtedly better, but we should use it with caution, right?

Yes, @CelsoCamarano, you should use this tip with caution, and I think Boston would agree, as he has requested an enhancement to the recent performance update you mentioned that would wait until the page has fully loaded and then fetch the data for hidden elements so as not to negate the benefits of the deferred drawing logic.

1 Like

Yes. You could add a condition to the list shifter element and in that condition set the datasource, so the datasource by default is empty.

The condition would be ‘page loaded entire is yes’…this way you can benefit from the page load improvement and the data load on hidden elements. This way the data for the list shifter is only fetched once the page has been fully loaded and benefitted from the improvement of deferred drawing.

1 Like

Excellent, I just read @boston85719’s post and understood the problem he is addressing here.

Very pertinent

@boston85719 , I have been too nervous to use ListShifter until now as I just couldn’t get my head around it when I originally looked at it some months ago. This video has been Extremely helpful and I have just improved my whole UX experience by unquantifiable amounts. I wish I had implemented this month’s ago. Custom states were just killing me and I was having some really laggy experience and far too many workflows until now.

Really grateful that you shared this, thank you.

1 Like

I missed this (funny) thread when it happened in real-time, but what Boston is doing is a very valid use case for List Shifter (especially if your page will use another List Shifter for other processing functions).

I use List Shifter instead of custom states quite commonly… even if I’m just storing a scalar (single / non-list) value.

As I think was pointed out somewhere in the thread above, if you’re storing the results of a search, List Shifter has an advantage (really just a different, but commonly useful way of operating) over Custom States in that, if the results of the Search change, List Shifter will reinitialize and magically now hold the updated values.

This is true for any expression that has variables that might change. So, consider a simple calculator that takes a number from Input A and a number from Input B and adds them.

Instead of writing workflows that trigger when input A or Input B change, you just put Input A’s value + Input B’s value into List Shifter’s “Use Scalar” and now the value at List Shifter’s Scalar output always contains the sum of those inputs. (Additionally, you know when the calculation changed because of the Updated/Initialized event.)


Now I need to play with the use scalar function :upside_down_face:

1 Like