Optimizing Experience Builder App Performance with Numerous Layers

[michael_a]

I'm encountering slow loading times and performance issues within my ArcGIS Experience Builder app. Currently, I publish web maps directly from ArcGIS Pro. I then utilize the published web map and the feature layers it contains within Experience Builder to build my app. For improved performance, would it be better to publish my map as individual feature layers in ArcGIS Pro and then build a web map using Web AppBuilder (WEB) within ArcGIS Online (AGOL)?

Additional Information:

• My map consists of approximately 60-70 layers, including a mix of lines, points, and polygons.
• Ideally, I'd like to enable functionalities within the Experience Builder app, such as allowing users to turn specific layers on and off or filter data based on certain criteria.

Expected Outcome:

My goal is to achieve a significantly smoother and more responsive user experience within my Experience Builder app.

Performance Optimization Considerations:

• I've explored simplifying symbology and labels within the web map.
• I'm considering utilizing data filters in WEB to manage the amount of data displayed at different zoom levels.
• I'm interested in learning more about the potential benefits of using tile layers for large basemaps.

I appreciate any insights or suggestions the community may have to optimize my ArcGIS Experience Builder app's performance, particularly when dealing with a large number of layers.

[SteveCole]

Seems to me that you having 60-70 layers *WITH* labelling is greatly contributing to your issues. That's a lot of back & forth queries going on with each map change. The conventional wisdom is to pare that down to make focused applications rather than a "kitchen sink" kind of app.

That being said, look at your layers and consider implementing visibility based on map scale.  Feature count rich layers like parcels shouldn't really be visible when zoomed out at a county level so keep those off until you're much more zoomed in.

Other factors could be things like are these all layers that you have published or are you pulling in 3d party services? If so, you are entirely at the mercy of the 3rd party's maintenance of their own services. Fed/State/Local government publish a lot of data that has a high up time but....things happen and servers can go down or the agency can republish content and change REST urls without notice. These all result in your app waiting to time out a request.

I do think that your biggest challenge is the amount of services in your application, though.

[michael_a]

Hi, thanks for the answer.

All my layers are being uplaod to AGOL. Doesnt it mean that the only service is AGOL?

[RhettZufelt]

From my experience, a basic map like that will greatly increase in performance if built with Map Viewer Classic and Web App Builder.  Unfortunately, WAB will be retiring soon and was hoping ExB would be a comparable replacement by then.

If I build the same basic map in WAB vs ExB see total load times of 5.3 seconds vs 22.8 seconds.  Have tested this on several web apps, and though the numbers are different, the increase in time is pretty consistent.

R_

[Laura]

I had similar issues. A large amount of data does make a difference. I talked to a consulting company. They had me start with consolidating all items in AGOL then I published my layers as group layers instead of all individual. Still takes some loading time but not horrible. 

[michael_a]

so you are basically saying it is better to publish the layers as web map (is that what you meant by group layer?) rather than individual layers?

[Laura]

Like instead of publishing water main, water valve, water cutoff on their own I would publish a general water layer.