Login

I’ve been building a client portal in Bubble and hit a wall where the performance just isn’t there for a key workflow with a lot of data. I’m wondering if I should try to optimize within the platform or if this is the point where I need to consider a custom backend solution, even though that defeats my original no-code goal.

I stuck with Bubble optimization first. Tweaked the data structure, cut the number of API calls, and used custom states to hold IDs instead of requerying the same list every render. I started returning only the fields we actually show, and moved heavy joins to an API workflow that runs in the background. On a mid size dataset, page load dropped from about 2.5 seconds to around 1.2, but when the dataset spiked to tens of thousands of rows it still dragged. Still different users, different devices, same page, and the bottleneck moved around.

Do you think the real bottleneck is the sheer number of API calls or the volume of data per request? I tried a dummy page with the same UI but a static dataset and it felt instantly snappier, which makes me wonder if the issue is queries or transfers rather than the UI.

POC time with a backend: spun up a tiny Node API to do the heavy lifting and expose a lean payload, then wired it through the API Connector. The response time dropped from about 2.5s on Bubble to sub 1s on the API call, and caching helped a lot. Still not a clean path yet, since deployment and maintenance add friction, and I’m not sure I want to tilt the project away from the no-code approach.

One memory: I found that loading extra fields I didn't show ate bandwidth, and the rest of the page waited. In the end I trimmed the view to essentials and delayed noncritical panels until after the main content rendered. It helped a bit, but the workflow still feels more fragile than I expected. Maybe the problem is the workflow design or the data model, not just the backend. Not sure.

Login
Username:
Password:	Lost Password?
	Remember me