Athar Ahmad on Bubble.io Performance: The Architecture Rules He Never Breaks
Slow Bubble apps are architecture problems, not platform problems. Athar Ahmad’s four non-negotiable performance rules, the five-step audit process for fixing a slow application, and the load time benchmarks he targets before every production launch.
Why Slow Bubble Apps Are Architecture Problems, Not Platform Problems
When Athar Ahmad audits a slow Bubble application, the cause is predictable before he opens the editor. Performance problems in Bubble are architectural. They are caused by specific, identifiable patterns that translate to expensive database operations. Every one of them is preventable with the correct architecture. Athar has never shipped a production Bubble application that a client described as slow. This is how.
Non-Negotiable Performance Architecture
Rule 1: Zero :filtered by
The worst performance anti-pattern in Bubble. Loads all records from the database to the browser, then filters in JavaScript. At 1,000 records: noticeable. At 10,000 records: unusable. At 100,000 records: the page never loads. Athar removes every :filtered by expression before any production deployment and replaces each one with a search constraint.
Rule 2: Pre-Calculate All Dashboard Metrics
Live count queries on dashboard render (Search for Tasks:count) perform a full table scan on every page load. With 50 users refreshing dashboards, that is 50 simultaneous table scans. Athar stores all dashboard metrics as denormalised number fields on the Workspace record, updated by workflows on every data change. Dashboards read stored numbers and render in milliseconds.
Rule 3: Paginate All Repeating Groups
Every repeating group in every production application Athar builds has a maximum of 20 items per page. Not 50. Not 100. 20. A repeating group with 500 items renders 500 DOM nodes simultaneously, creating browser memory pressure and scroll lag. 20 items per page renders 20 DOM nodes regardless of how many total records exist.
Rule 4: No Deep Relational Chains in RG Cells
Accessing Current cell’s Task’s Project’s Workspace’s name requires three separate database queries per row. In a repeating group with 20 rows, that is 60 database queries per render. Athar denormalises: stores project_name and workspace_name directly on the Task record. Each row reads from one record, not three.
How Athar Measures and Fixes
Measure baseline page load times
Before any change, measure and record page load times for every page in the application using browser developer tools. Focus on the dashboard, the main list views, and any page that users spend the most time on. Record the times. These are the benchmark.
Search for :filtered by across the entire app
Use Ctrl+F (Find) in the Bubble editor to search for ‘:filtered’. Every result is a performance problem. List them. Fix each one by replacing with a search constraint. Remeasure after each fix to confirm improvement.
Audit every dashboard element’s data source
For each text element on the dashboard: click it and check the data source expression. Any expression containing ‘:count’, ‘:sum’, ‘:average’, or ‘:min/:max’ from a search is a live calculation. List them. Move each one to a denormalised field on the Workspace record. Add update steps to the relevant workflows.
Check all repeating group pagination settings
For every repeating group in the application: check ‘Items per page’. If it is set to ‘All items’ or more than 20: change it to 20 and add pagination buttons. If items per page is already 20 or less: confirm Next/Previous buttons exist and work correctly.
Remeasure and compare
After all fixes: remeasure page load times against the baseline. Document the improvement. Send the before/after comparison to the client. In Athar’s experience, applying these four fixes reduces dashboard load time by 60-90% in applications that had all four anti-patterns present.
The Numbers Before Launch
| Page | Target Load Time | How Achieved |
|---|---|---|
| Dashboard (main) | < 2 seconds | All metrics from denormalised Workspace fields; zero live queries |
| List pages (repeating groups) | < 3 seconds | 20 items per page; search constraints; no relational chains in cells |
| Detail/record pages | < 2 seconds | Single record load; related data via direct field access |
| Search results | < 1.5 seconds after typing stops | Search constraints only; 100ms debounce on input changes |
| Initial page load (first visit) | < 4 seconds | Bubble CDN; image optimisation; no blocking external scripts |
Work With Athar Ahmad
Pakistan’s leading Bubble.io systems architect. Multi-tenant SaaS architecture, Stripe billing, AI integration, and full product builds designed and delivered with precision.
