Optimal strategy for Experience Builder with many widgets and data

Nadia_Matsiuk — Tue, 14 Oct 2025 12:57:01 GMT

Hi everyone,

I’m working with Experience Builder Developer Edition and have developed an interface that includes:

static cards with dynamic text,
a map with object information and a legend,
multiple charts of different types (around 12–15),
a filter widget for all of these.

Problem: the page loads very slowly.

I’ve investigated:
Using developer tools, I see the page sends almost 1000 requests, with 200 requests going to my ArcGIS Server. I analyzed these requests in detail: most are querying my data source, fetching fields and performing calculations for the widgets.

I’ve tried some optimizations:

creating views with only the necessary fields,
including only layers and tables that are actually used,
indexing the database.

These measures helped a bit, but the page is still extremely slow.

I’m looking for a comprehensive strategy:

How should such pages be designed in Experience Builder when there are many widgets and charts?

How to plan the server-side architecture, load balancer, and database setup?

Is Experience Builder suitable at all for pages of this complexity?

I would really appreciate detailed recommendations and best practices, especially from Esri developers🌎💛

Re: Optimal strategy for Experience Builder with many widgets and data

Wei_Ying — Mon, 17 Nov 2025 19:39:38 GMT

Thanks @Nadia_Matsiuk for your feedback.
How many charts are you having in a single page?

Re: Optimal strategy for Experience Builder with many widgets and data

Nadia_Matsiuk — Tue, 09 Jun 2026 09:00:13 GMT

Hi @Wei_Ying ,

Thank you for following up.

I currently have around 12–15 charts on a single page.

To give more context, the charts are only part of the workload. The same page also contains:

several static cards with dynamic text / KPI-style values;
one Map widget with object information and a legend;
multiple feature layers and tables used by the widgets;
one global Filter widget that affects the charts, cards, and map.

The main issue is the initial page load and the number of requests generated by the page. In DevTools, one page load produces approximately 1000 total network requests, including around 200 requests to ArcGIS Server. Most of the ArcGIS Server requests appear to be related to querying data sources, fetching fields/metadata, and calculating statistics for widgets.

I have already tried the following optimizations:

created data views / service views with only the fields required by the widgets;
included only the layers and tables that are actually used;
indexed the database fields used in filters, joins, and statistics;
reduced unnecessary fields where possible;
reviewed standard Experience Builder best practices such as splitting content into pages/views, using lazy loading where possible, limiting visible/active content, and simplifying data sources.

These steps helped a little, but the page is still too slow.

My question is not only “how to make one chart faster”, but rather what the recommended architecture is for an analytical Experience Builder app of this size.

Could you please advise on the following?

Is having 12–15 Chart widgets on one page considered above the intended or comfortable range for Experience Builder?
For a page with many synchronized charts and one global filter, what is the recommended pattern:
- one shared data view,
- separate optimized data views per chart,
- pre-aggregated tables/materialized views,
- ArcGIS Dashboards/Insights,
- or custom widgets/API-level aggregation?
Are there any recommended limits or reference architectures for complex Experience Builder apps that behave more like a geoportal or analytical dashboard, rather than a small app with one map, a list, a few filters, and a few charts?
From the ArcGIS Server / enterprise geodatabase side, what would Esri recommend for this type of workload: pre-aggregated services, separate services for analytics, specific service settings, load balancer considerations, database indexing/statistics strategy, or another approach?

I would really appreciate a concrete design recommendation or reference architecture for complex analytical Experience Builder apps. Most documentation and examples I have found are helpful, but they usually cover smaller projects. In this case, the business requirement is a larger geoportal-like interface with many synchronized widgets, so simply reducing the page to a few charts is not always possible.

If useful, I can also provide more details about the network requests, data source structure, chart types, and ArcGIS Server configuration.

Thanks again!

topic Optimal strategy for Experience Builder with many widgets and data in ArcGIS Experience Builder Questions

Optimal strategy for Experience Builder with many widgets and data

Re: Optimal strategy for Experience Builder with many widgets and data

Re: Optimal strategy for Experience Builder with many widgets and data