Boost your Bubble app performance by prefetching data in advance 
Prefetching in web development is like preparing things youāll need in advance so you donāt have to wait later. It involves loading parts of a website or certain data before you actually need them. So, when you click on a link or need that data, it loads much faster because it was already prepared in advance.
Nice video. Thanks for sharing.
I understand the video is not about design, but just thought to suggest that instead of setting your āhiddenā elements to 1px by 1px and placing them at the top of the page, you can instead add a floating group to the page, make it float beneath the page and add all those āhiddenā elements to the floating group so they are completely out of the way of other visible elements and do not disrupt your design/layout in any way. Another benefit, is all of those āhiddenā elements are in one place and easy to locate again.
Also, custom states have no DOM representation. So why not just use states., eh? (I havenāt watched the video because thereās no magic here.)
āWhenever I hear hidden elements, I reach for my gun.ā
Dude thatās brilliant. 
How come Iāve never thought of this! You can imagine how many times Iāve struggled fixing gap spaces and paddings to accommodate hidden elements on the page.
Iām just wondering if it has some flaws when underneath the page. Do you use Var elements like that?! 
@keith lol for sure! I was just like that for a very long time. Custom States have some limitations when it comes to setting default values or when you want them to be updated automatically without setting a state from workflow tab. (In some cases).
Not the case all the time but having Variables on the page have their own benefit over CS. In fact I have Var vs Custom State video coming up. Iāll cover the difference and tag you in the video! 
I didnāt watch the full video but hidden element pre loading in my experience when auditing client apps is very rarely ever a net positive. Most people use it with such bad practice that their entire app is taking massive hits in speed, taking multi minutes to load, and/or becoming completely unresponsive. It may work well for a few rows of data or max a couple hundred but at even small scale itās bad practice.
All it takes is 1 hidden element trying to preload 1000+ (maybe even a few hundred if itās heavy data) rows of data with a filter attached to completely lock up the app.
Although itās great info itās not something to be used by the majority of people.
If the data canāt fluidly be displayed with ādisplay allā then it shouldnāt be preloaded & if it can be fluidly displayed with ādisplay allā then preloading isnāt really necessary.
Hey thanks for taking time to share your opinion!
Second part of the video is about prefetching with pagination or downloading only parts of the list for speed/performance purposes.
Anyway is pre-fetching a bad idea?! āHell noā. Can it be mal-used āoh for sureā. This being said I think the whole concept of development is like that. There are no right and wrong answers - thereās only specific cases and each have its own answer.
Anyhow you can subscribe to bestbubbledev youtube channel and help me get to 1 million subscribers in 2024 
None the less, youāre a great creator of educational content and itās good info for people to have itās just a slippery slope for most people to use.
Keep up the teaching 
And round and round we go. 
Edit: I should have mentioned that I agree with Chris about your content, Gio. If I was on the youtubes (or ever left the forum, for that matter), Iād subscribe. 
LOL
I think as much resources and methods has to be shared as possible. We, the bubble devs, can be the judge of what methods we want to adopt or ignore.
For instance things can go wrong when using html element or toolbox plugin. One may paste a code that interferes with Bubbleās native code and break something.
Nevertheless we want people to share how they use either html element or toolbox plugin for running JS.
What do you think?! @mikeloc
I use it for elements that might need to be available as a datasource with dynamic expressions that perform the calculations I need, so I guess that is the Var element. I also put plugin elements into it as well.
So, no flaws, except on some plugin elements like the Countable which is necessary to be on the page next to the input element it is set up to count, although, it is not always the case with that specific plugin, which in itself is an issue with that specific plugin.
I hide list shifter elements in those floating groups 
Thereās no need to do that, you know.
It is simply for design purposes. Can not make the list shifter element 0px width by 0px height, so I just put it into the floating group set beneath the page so it doesnāt interfere at all with design/layout of the pageā¦it is not actually hidden, it is just inside the floating group beneath the page elements
Another issue to consider is the fact that pre-fetching for dropdowns leads to a significant WU hit every time a user opens a page. When auditing one of our apps we noted that one dropdown in particular (a dropdown of countries!) was causing the WUās to rack up - even if the user never ended up clicking on the dropdown.
We did the opposite. We had the dropdown. by default, only load the first item. If the user touched or hovered over the group containing the dropdown a workflow directed the dropdown to load the entire list. It led to a lag, but it significantly reduced our WUās for that page.
Pagination for RGās is a great idea.
Great point thanks for sharing!
WU is the worst nightmare of all of us I guess
Nah, itās really not.
Once you get past the facts that 1) WU just is what it is, 2) Bubble needs to make money in order for this platform to exist (and like it or not, WU is the model they have chosen to make that money), 3) you need to build with costs in mind (which isnāt a concept that is specific to Bubble and/or that only came into being because of WU), and 4) you need to have a business model that more than covers the costs you pay to Bubble, WU is nothing more than just another aspect to consider during your build.
Case in point, I only have one app on a paid plan these days, and while the scale is not big by any means, the app has me pocketing 10x the amount I pay to Bubble because of WU. So, just one data point and one personās opinion, of course, but WU isnāt a nightmare for meā¦ it just is what it is. Once you reach that point, Bubble goes back to being the mind-blowing platform that enables us no-coders (sorry, programmers, and no offense, Emmanuel, but thatās old news, my friend ) to do things we only dreamed about or paid others to do for us before Bubble came along.
