Lewati ke konten utama

Dashboard loading slowly

A dashboard that takes more than ~3 seconds to render is almost always one of three problems. In order of frequency:

1. The queries are slow​

Open the dashboard in Inspect mode (admin → Dashboard → Inspect or ?inspect=1 in the URL). Each tile shows its query timing. The slow tile is rarely the one you'd guess.

Common fixes:

  • Missing aggregation — a tile pulling 50K raw rows to compute a single number should pull the aggregate. Add a SQL recipe upstream that does SELECT COUNT(*) FROM ... so the tile fetches one row.
  • Missing index — if the tile filters on a column that isn't indexed in the source, every dashboard load triggers a full scan. Either add the index in the source DB, or materialize the filter into a precomputed dataset.
  • Cross-database joins at render time — joins between a Postgres connection and a CSV upload happen in Honeyframe's process and are slow. Either denormalize upstream or use a SQL recipe to push the join into one of the databases.

2. Too many tiles​

A dashboard with 30 tiles fires 30 queries on every load. Even if each is fast individually, the browser's request concurrency limit means they queue.

  • Combine tiles where possible — three KPI numbers from the same dataset can be a single tile with three numbers, fetched as one query.
  • Use a drill-down pattern: top-level shows 4 summary tiles; clicking opens a detail dashboard. Most viewers never click through, so 90% of the load is saved.
  • Move "always loaded" but rarely-watched tiles into collapsible sections; collapsed tiles don't query until expanded.

3. Browser cache / stale assets​

If the dashboard was fast yesterday and slow today and nothing changed in the data:

  • Hard-refresh in the browser (Cmd+Shift+R / Ctrl+Shift+F5)
  • Open in a private/incognito window — confirms whether the issue is browser-cache or server-side
  • Check Network → DevTools for any single request taking 10+ seconds; that's usually a stuck WebSocket or a network blip, not the dashboard itself

If incognito is fast and regular browser is slow, the user's browser cache is corrupted. Clearing site data fixes it but ask: did a recent deploy bump asset versions?

When the dashboard is slow only for some viewers​

That points at a per-user filter or permission causing extra work:

  • Row-level filters — if the dashboard has an RLS policy that joins to a permissions table, and the viewer's group has 10K matching rows where another user's group has 100, the queries take 100× longer for that user. Audit the RLS join condition.
  • Column masking — masking applies after the query, but on dashboards with hundreds of columns, the masking overhead becomes visible. Reduce returned columns to only what tiles actually display.
  • Group-based filtering — if a tile filters on a parameter populated from the viewer's group memberships, users in 20 groups get a WHERE group_id IN (...) 20-element list, which can defeat indexes.

Diagnostic order​

Reproduce in incognito
   ├─ Slow → server-side problem → continue
   └─ Fast → browser cache → user issue, fix locally

Inspect mode → which tile?
   ├─ Single tile slow → fix that query (sections 1-2)
   └─ Many tiles slow → load shed (section 2)

Per-user variance?
   ├─ Yes → RLS / masking / group filter (section above)
   └─ No → general slowness, treat as backend tuning

See also​