After building production grade apps for several years, I’ve realized that most ‘Bubble is slow’ complaints aren’t about Bubble they’re about how we structure our data and workflows.
Here are 3 things I check first when I’m brought in to optimize an app:
The ‘Search for’ Trap: Stop putting complex ‘Search for’ expressions inside Repeating Group cells. Use ‘Group variables’ or ‘Custom States’ tohold your data once.
Backend Workflow Overload: Moving logic to the backend is great, but un optimized recursive workflows can eat up your Workload Units (WU).
Privacy Rule Gaps: If your app is slow, check if you’re filtering data on the client side (front-end) instead of the server side. Proper Privacy Rules = Faster Apps.
I’ve used these principles to scale apps from 'laggy MVPs’to snappy, professional products.
I’m currently opening up my schedule for new projects and long-term Bubble Developer roles. Whether you need a performance audit, a full build from scratch, or an AI integration (OpenAI/ElevenLabs), I’m happy to help.
In my app I have a schedule (like a calendar) that in each hour time it looks if there are events. They need to be dynamic because it changes all the time. Is there any workaround on that?
What I do → there is a repeating group searching for the events on the week, let’s call “Repeating all week”.
Then in each cell there is a condition “When Repeating all week’s times contains this time → Repeating all weeks:filtered (time = current cell’s time)
Idk if this is the best way. The times are in option set already.
The main issue with your current approach isn’t that it won’t work, it’s that you’re doing filtering inside each RG cell, which means Bubble is re evaluating logic over and over again. That’s usually where performance starts to hurt.
A couple of cleaner alternatives you can consider: 1. Pre-group the data once (outside the cells)
Instead of filtering per cell, try loading all events for the visible week once (either in the parent group or via a custom state). Then inside each hour cell, you only check against that already-loaded list.
→ Same result, far fewer searches. 2. Use time ranges instead of “contains time”
If possible, store events with a start_datetime and end_datetime.
Then your condition becomes something like:
event’s start ≤ current cell time AND event’s end > current cell time
This avoids option-set matching and scales much better. 3. Avoid :filtered inside repeating groups
If you must filter, do it at the RG data source level or via a state, not per cell. :filtered inside cells is usually a red flag for calendars and schedulers. Your approach is totally understandable (a lot of people build calendars this way at first), but if the schedule grows or updates frequently, you’ll definitely want to shift the logic up a level so Bubble isn’t doing repeated work per cell.
Sorry, I don’t see how it would solve my problem of making the schedule dynamic…
What I need:
A weekly schedule UX with the time stamps even if there aren’t events (we click at the time to create an event)
The even should appear inside the time placed → It shows more details like what kind is the even, how many people are there, etc
This schedule is shared through many users. If an event is created or removed by others, it needs to refresh immediatly. So I can’t make the list of events static.
