Performance optimization

Adriel dashboards can pull data from many connected sources, join across breakdowns, and render dozens of widgets on a single view. As dashboards grow, performance can slip. These are the highest-leverage things a dashboard builder can do to keep dashboards fast.

​

Keep the widget count reasonable per dashboard

Each widget fetches its own data. A dashboard with 50 widgets makes 50 independent fetches — the more widgets on a single dashboard, the more concurrent work the backend has to do, and the longer the total load time. As a rule of thumb, aim for 10-20 widgets per dashboard for optimal responsiveness. Beyond that:

• Split the dashboard into multiple smaller dashboards, each focused on a specific reporting angle (Overview / By channel / By campaign / and so on).
• Use folders to group the related dashboards together in the sidebar.

Splitting dashboards keeps each one snappy and lets users navigate to the view they actually need without waiting for irrelevant widgets to load.

​

Narrow the date range where possible

Every widget’s query pulls data across the dashboard’s date range (or the widget’s own override). Wide date ranges — 12 months, 24 months — take longer than narrow ones like 7 or 30 days. Practical tips:

• Set the dashboard default to the most common date range for that report (usually last 7 or 30 days). Users can widen from there when needed.
• Use per-widget date overrides selectively — for example, a “YTD Spend” tile can carry its own longer range while the rest of the dashboard stays on 30 days.
• For long-range trend charts (like a rolling 12-month line chart), place them on a dedicated “Trends” dashboard so the shorter-range operational dashboard doesn’t inherit the wide range.

​

Choose breakdowns carefully

Breakdowns multiply the number of rows a widget has to compute and render. A table with breakdowns Channel → Campaign → Ad set → Ad on a workspace with hundreds of ads can produce thousands of rows.

• Start with the coarsest breakdown (Channel or Campaign) and add depth only when needed.
• For chart widgets that use Group by, prefer breakdowns with a small number of distinct values (Channel: 3-5 values) over ones with many (Ad name: hundreds).
• On tables, use widget filters to narrow to just the campaigns / ad sets / ads relevant to the widget — filtering at query time is much faster than sorting through thousands of unfiltered rows.

​

Use widget filters, not dashboard filters, for narrow scoping

Dashboard filters apply to every widget on the dashboard. Widget filters apply only to that widget.

• If a scope only applies to one widget, use the widget filter — it’s more targeted and doesn’t force other widgets to re-evaluate their queries.
• Reserve dashboard filters for scopes that legitimately apply across every widget (a specific date range, a specific ad account for the whole dashboard).

​

Split heavy tables from summary widgets

A single Ads Table with deep breakdowns and 10 metrics can dominate a dashboard’s load time.

• Put the heavy table on its own dashboard (or its own section separated by a notepad header). Users who need the full breakdown navigate to it; users who just need summary numbers get a fast summary dashboard.
• Consider using the Small table instead of an Ads Table when only a few columns are needed — it’s lighter to render.

​

Take advantage of lazy loading

Widgets below the visible area of the browser don’t fetch data until they’re scrolled into view. This means dashboards can be long without paying the full performance cost of every widget upfront — the widgets a user sees first load fastest, and later widgets load as the user scrolls. Practical use:

• Put the most important widgets at the top of the dashboard so they render first.
• Long detail tables at the bottom of a dashboard don’t slow down the initial load.

​

Watch for widgets that time out

If a widget consistently takes an unusually long time to load, or shows a timeout error, its query is too heavy for the current setup. Options:

• Narrow the date range.
• Reduce breakdowns.
• Add a widget filter to scope the data.
• Split the widget into two smaller widgets covering different scopes.

If timeouts persist after all of the above, contact support at support@adriel.com to look into the specific data source and query.

​

When performance issues persist

If a dashboard still loads slowly after applying these tips:

• Check whether one specific widget is the bottleneck (loading spinner sticks on it longest).
• Confirm the source data sources are refreshing on their expected cadence — a stale source can cause queries to fall back to slower paths.
• See Data not loading for other reasons a widget might not load.

​

Troubleshooting

​

Related