Boost app performance - Prefetching Tutorial 🔥

Boost your Bubble app performance by prefetching data in advance :point_down:

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.

:movie_camera: Watch it here


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. :star_struck:

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?! :thinking:

@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! :heart_hands:


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! :heart_hands:

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 :grin::heart_hands:

1 Like

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 :muscle:


And round and round we go. :wink:

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. :slight_smile:


LOL :grin:

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

1 Like

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 :man_shrugging: :gun: :face_with_head_bandage: :stuck_out_tongue_winking_eye:


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.

1 Like

Great point thanks for sharing!

WU is the worst nightmare of all of us I guess :grin:

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 :wink: ) to do things we only dreamed about or paid others to do for us before Bubble came along.