Forum Academy Marketplace Showcase Pricing Features

Groups and there relation to performace

Hey everyone,

First of all I’d like to say to any newer Bubble users: learn to use groups!
Rather then “changing pages” hiding/showing groups will significantly speed up your web apps!
For the bubble alumni, I am wondering what people think on this issue:

Do you think (or know) which of these methods would result in better performance?:

Workflow = hide group 1 > hide group 2 > show group 3

assuming it is applicable:
Putting group 2 inside of group 1 then:

Workflow = hide group 1 (which now contains group 2) > show group 3

Is one method significantly better than the other for perform ace? Or are they more or less the same

I ask because. I am wondering if I should amalgamate some groups, to reduce workflow - but sometimes copying and pasting entire groups can lead to issues.

Thanks for any thoughts



I believe that the best thing that you can do to condense your workflow/speed up performance when changing groups is to create a field for the current user called “view” (numerical value) and use conditionals to show/hide groups based on that.

For example:

Groups 1 and 2 are only visible when “Current User’s” view is 1. Group 3 is only visible when it’s 2.

Therefore, running a workflow that changes the current user’s view to 2 hides groups 1 and 2 and shows group 3 simultaneously.

This method saves a ton of time and space when setting up workflows.


:point_up: this :slight_smile:

1 Like

Hey thanks @natedogg that definitely sounds like the way to do it!
Thanks for the great explanation.


I don’t switch between pages, i show and hide groups all in one user dashboard as you stated above. I used to do it as a field change on a user but I changed it to a set a custom state. Changing a field on a user counts against your monthly workflows whereas setting a state doesn’t. If the user is constantly switching between tabs to show and hide groups, your workflows will add up pretty fast.


Hey man that is a great observation; I was thinking that the other day as well.

I’m convinced that at a millisecond level - to hide a group (or multiple groups in this case) in the workflows, that are not even visible, is a programming superfluity that may result in a subtle performance issue.

I feel that the “current users view” method would perform cleaner for back end code

  • I don’t actually know though! Thats the thing :confused:

There may be a middle ground. Some sort of hack with custom states possibly.

  • your method is definitely good @denverdave11 but my particular layout would require a smorgasbord of hide/show sequences (only because i want to reduce the actual workflow blocks)…
  • If I didn’t mind having 15 separate workflow boxes that hide/show only specific groups at a time; that would definitely be the way, yes.
1 Like

No you would only have a workflow to set a custom state on your tabs group (or whatever you are using) and all of the hiding and showing is done on the element as a condition. I think I have 4 set state workflows and another one on when page is loaded.

1 Like

Ya you could be right. I will play around with it.

I have found instance where: if a particular group is shown via a workflow - it therefore has to be hidden via a subsequent workflow as well. There are instances where a group will still be visible even when conditions state that it shouldn’t be…

By using set state workflows - are you able to leave your groups hidden by default?

An issue I’ve found is: If i am relying heavily on conditions , without many workflows - my groups have to be visible by default (which is a confusing disaster)… or have to have a “show group” workflow - but as i mentioned, the “show group” workflow can initialize the chaos.

I will try doing what you do! Thanks for your help

It would be great if when the user presses the back button, it takes them to the previously shown group instead of the previous page. Like you would find when backing out of an email in Gmail. However, that would probably mean an implementation of a new kind of group specifically made for that.


Ya, that would be cool! I agree
It may be tricky to differentiate when the back button should go back a page or to the previous group; as the end-user would need to be in control of that decision on their end.

That could definitely save some screen space though :grin: