Please do. Also highlight issues from issue checker you experience during the process
@georgecollier is this true 
Just test quickly by using console and dev tools in browser.
Elements using conditions directly on them to show/hide are basically just display: none unless the condition is true. That means the element is still loaded into the DOM — because the condition lives on the element, so the element has to exist in order to evaluate the condition.
If the condition is handled in a workflow instead, then it becomes decoupled. The element switches to conditional rendering and won’t be loaded into the DOM until it’s explicitly revealed by a workflow.
This is one of my pet peeves with Bubble — it makes page load optimization frustrating and very difficult. Using workflows to control visibility is more work than just using conditions, and it clutters up your workflows fast and it’s not intuitive.
I like using conditions instead of workflows anywhere I can for visibility. Definitely is more efficient in terms of development and maintenance and debugging.
I never really thought about how an element set to not visible on page load, with no conditions to make it visible but has workflows to show it, would not be automatically loaded into the DOM as every other type of element would be, but it makes sense that it is. I personally do not believe there is much page load speed impact between the differences though.
I’m in the same camp.
Bubble makes it quite hard to optimize page load by doing the “workflow to reveal” method so I don’t bother with it even though it is the optimal way if you care about page load speed and size.
It would be great if there was a way to do conditional rendering on the element (other nocode builders do this so no reason bubble can’t)
In most of case it doesn’t affect the speed in a significant way, yes.
But in this specific case, it loads 100 lines of hidden row in DOM in the RG so yes, impact is huge ;). 4 to 6 seconds in page load is really huge.
And yes, it’s true. You can quickly test it with chrome dev tools DOM inspection in live. You’ll see DOM loading/loaded 
I’m not that familiar with console tools but what I see if an RG is set to visible on page load I get these results
And if that same RG is not visible on page load with no conditions to make it visible I get these results
I can not make sense as to why if the RG is not visible on page load with no conditions and it is the same exact set of data why it is the DOM load is longer, but what I see as a difference is that when RG is visible on page load, the Largest Contentiful Paint is the same as the First Contentiful paint, which is different if the RG is visible. I don’t know enough about the differences between first and largest contentiful paint, but that seems to be related to the data in the RG being visible to the user above the fold of the page.
Is that what you see as well, that the first and largest contentiful paints are the same once you make the RG hidden with no conditional visibility and only show it via a workflow action to show element?
Make sure you reset your cache between tests, this has a huge effect on loading times in dev tools.
Hi,
I tried to figure that too but didn’t succed.
But what I arrived to was that workflow visible enabling don’t affecet the DOM as conditionnal visible enabling.
In both cases default is set as unvisible.
In my case it’s a particular case because it’s not the RG it self that I show/hide. It’s a secondary line.
Here is a screen shot of what opens and hide :
The first one is a close row never opened yet.
The second is an open row, became visible after clicking on the row in the RG.
And here are the DOM loaded elements. First not opened, you’ll see DOM element div BaTHapk is empty.
And when opened, it’s filled with DOM content.
It’s not related to data loaded, because i tested it a lot because, even if I never load data, behavior is exactly the same.
Before working with workflows for making visible disable, i obviously used conditionnal with default not visible and data not loaded.
In the DOM, all line where preloaded with no data inside, but with the entire structure ready.
And for a complex DOM structure in a 100 row RG, it’s a game changer.
I don’t know, but it actually doesn’t matter.
This user is expericing load times of 12-20 seconds when clicking something. That’s not an issue about loading elements in the DOM, it’s probably about data loading etc.
This is insane and will cause OP problems later when they can’t work out why some stuff is showing and others are hiding
And here’s the root cause
We have apps with hundreds of reusable elements on a single page, and no noticeable performance impacts. Ensure stuff is only visible when it needs to be, minimise ‘page is loaded’ workflow (or constraint them to only run when element is visible) and you’ll be fine.
Hi,
Seems you didn’t see anything about what I wrote, but that’s ok
Hope what I wrote helped the people needed it
Have a good day all !
I know what you wrote! The root cause of your loading time problems is a data loading issue, not an element loading issue.
I promise you’ll kick yourself in a few months if you implement show/hide actions widely 
My 2 cents here, a guy told me to not use bubble built plugins so I removed google material icons so I removed every google material icon and changed it to regular icon element, my DOM was red in dev tools (don’t remember the item number) and now it is grey, page load went down fcp, 1.5 secs. I have 0 clue how the rendering happens but surely there is differences in rendering.
Note: You can check it by creating 10 groups, making it all invisible and to the most inner part put a bubble built plugin element, than inspect the page with dev tools, you will see all 10 groups rendering and then try testing with out that plugin
This is something a Bubble dev discussed during the latest Bubblecon.
Do we have link ?
Honestly great advice 
There are only two companies I avoid plugins from ahahahah and Bubble is one of them
Not specifically about Bubble plugins but he talks about how plugins in general increase page loads. I try not to use clientside plugins for this reason.
Wish they’d fix this:
I didn’t know that, so every time I created a reusable felt my app is getting slower and slower, turns out material icons was the case.
Need the second company ASAP
I am not saying that yes overall 95% of client side plugins are bad for performance but bubble built plugins actually renders your DOM, loads every outer group that the plugin is in