This floating group approach is not really based on floating group. So the use of the floating group is to be able to get the elements it will hold out of sight of the user and out of the way so as to not affect responsiveness of the page. This is why the floating group is used as the container of the elements inside and is set to float beneath the page.
What is inside of the floating group, as I use it in all of my apps are plugin elements and other elements like repeating groups or groups that are not to be displayed but are used to store values that will be repeatedly referenced by other elements on the page that are displayed to the user.
So, for example, if there is a search that is needed multiple times on the page because there are multiple elements that need to display a value from the search, and the search is for a single item, create a group that is placed into the floating group. That group will have a data source that is the search. Then for each element on the page displayed to a user that needs a value from the data entry, the dynamic expression will reference the groups ‘thing’ rather than having to perform another search.
It is unclear via Bubble documentation whether or not we are getting charged WUs for each time the search is listed on the page, so it is not completely clear how much WU savings there are to be had with that approach. However, having spoken to Bubble support prior to the WU pricing introduction, I was told the same search used in multiple elements on the same page is actually only performed once, and those discussions were focused on page performance and speed, so it could be the case that Bubble is charging WUs for each time the same search is on the page, even though they may just be performing the search once. The reason I would believe it is possible we are charged for each time the same search is on a page, is that we are charged WUs for each entry in a backend workflow parameter that is a list of things when running recursive backend workflows, which seems wrong since we are already charged WUs to retrieve those items to populate that parameter when scheduling the backend workflow the first time.
I was expecting to have saved you some WUs with the changes we made, but reducing your WU consumption by over 97% is a surprise to me. I hope those numbers are correct.
Best and easiest thing to tackle first are the searches. Checking in the editor using the WU tools currently available, any searches that are consuming a lot of WUs, look at ways to eliminate them. If they are in a workflow action but the data is already on the page, reference the data from the page instead of performing the search in the workflow action. If there is a search being used as a constraint in a search, find ways to eliminate the need for the search as a constraint, which may be as simple as adding a data field to the data type of the main search. Any data types that are searched for that do not need to be dynamic from the standpoint of allowing users to create/modify those values and they are for the most part relatively static, use an option set instead, even if that means biting the bullet and spending an hour to populate an option set with 100 options. An example of that might be if you have a data type for countries, and you are searching for those countries to display to users, change that to an option set.
Other things with searches, are the number of fields returned versus needed. So, if you have a search results page for products and the product cards only display 5 fields of 30 that are on the product data type and the filter feature only references 5 or 10 fields, consider having another data type created that is used only for the search page to cut down on the number of characters returned. Since Bubble charges per character returned from the server, you may be overpaying greatly based on the number of characters returned for the search.