High WU Usage for Dropdown with Large Dataset (1600+ Records) – Need Optimization
I have a single-page app with multiple reusable elements controlled by URL paths (e.g., app/clients to show the Clients reusable). Inside my Tasks reusable, I have:
- A Main Repeating Group (RG) with pagination (30 records per page).
- A filters section, where users can filter tasks by Record Status, Task Priority, Task Status, and Related Client.
The “Related Client” dropdown allows users to select an existing client, updating the Main RG to show tasks linked to the selected client. However, this dropdown is causing extremely high WU usage.
Methods I Tried & Issues:
I have 1600+ client records, each with 32 fields, and I’ve tried the following approaches, but all have inefficiencies:
Method 1: Direct Search in Dropdown Choices Source
Dropdown Choices Source: Do a Search for Clients (Constraint: Record Status = Active)
Issues:
- Each time the dropdown opens, it triggers a new search, causing heavy WU usage.
- Slow performance due to real-time database querying.
Method 2: Hidden RG to Preload Clients & Reference It in Dropdown
Setup:
- A hidden Repeating Group (0x0 px, visible on page load) loads all clients:
Do a Search for Clients (Constraint: Record Status = Active)
- Dropdown’s Choices Source:
This RG’s List of Clients
Issues:
- Still very high WU usage (Metrics: 374 searches, 1940 WU, 53.58% of total WU).
- Loads all clients on page load, causing unnecessary data retrieval.
Method 3: Using a Custom State to Store Clients on Page Load
Setup:
- On page load, store all clients in a custom state and use that for the dropdown.
Issues:
- Page timeout & lag due to storing 1600 records with 32 fields in memory.
- Causes severe performance degradation.
Constraints & Requirements:
- Option Sets are not viable (Client data is dynamic, and users create new clients frequently).
- I need a solution that significantly reduces WU* while ensuring the dropdown remains fast and responsive.
- The dropdown should always have the latest client data without excessive database queries.
Looking for Solutions That:
Reduce WU usage (currently at 1940 WU for just this dropdown). Improve performance (no excessive page load times, timeouts, or lag).
Keep the dropdown data updated dynamically (without frequent searches).
What is the best approach to optimize this? Any help is appreciated!
several things here
32 fields is likely very heavy data - depending on the fields but I’m assuming several long text fields
not sure why you’d be loading all 1600 clients on page load - the user would likely only have 10-20 active clients at a time, plus you are constraining to status = active
if they really did have 1600 active clients then a dropdown list would be extremely inefficient way to find a client. a search box would likely be better - this you can also restrain to 5-10 results for optimum performance
the main issue is likely the size of the data record
the secondary issue is likely insufficient filtering and constraints
As pointed in about, 1600 clients isn’t a dropdown, it’s a library. Use a searchbox element.
1 Like
The thing is i did use Bubble default Search box along with Fuzzy & Autocomplete Search The following are the results
Hidden RG Method
- Total Searches = 1215
- WU Consumed = 5856
- 1 Search Costing around = 4.82 WU
Fuzzy Search and Autocomplete Plugin from Zerocode
- Total Searches = 347
- WU Consumed = 2424
- 1 Search Costing around =6.99 WU
So the Search box method is consuming more compared to the Hidden RG method Tried using Bubble Default Search box but it can only search for 1 field i want to search using 2 fields for example Client Name or Client Email
Tried using Custom States Same Not Viable for 3 reasons
- Setting states got more expensive for large list of 1600 records
- Holding 1600 records in custom state made the app lag , Slow , Unresponsive and Multiple Sometimes it got Timed Out
- Since i use Go to page navigation the Custom sates are getting rest and set again Every time user navigates from one section to another
Cannot Use Option Sets as the Client Data is Dynamic i cannot store and Update the Option Sets Every time
Also all the results Above are for one Single day
how are you getting to 2400-3600 wu consumed when one search is 5-7wu?
are you doing the search within each row of the repeating group?
are you doing the search multiple times? - possibly because of reuseable elements or page reloads or group data changes - forcing searches to be refetched?
I wouldn’t try and hold 1600 records on a page - I don’t know why you’d need to do that.
search for task - constrained to status, priority, client
client = value of dropdown or search box
drop down or search box should be a search that uses ~5 wu
tasks should use about ~5wu
so total should be around 10wu + data - no where near 2400-5000wu
the issue is what are you doing on the page that is multiplying the search to use 2400 wu (assuming it is the search that is the issue there and not something else)
Fuzzy search is terribly WU inefficient. Don’t use it. It requires downloading all of the possible results to the client where the filter is done.
Use the Search Box element from Bubble. That’s all you need.
If you want to search multiple fields, have a search field on that data type that contains the fields you want to search. So, if you want to search the name and email, use a database trigger to set the search field to ‘Thing now’s Client Name | Thing now’s Client Email’
You probably also have a nested search that is performing a search for each Thing. What are your search constraints?
