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. 

[TD1]

I'm experiencing that same considerably longer load times in Experience Builder vs WAB. I have a WAB app and an Experience Builder app based off the same data and map with Experience Builder having considerably longer load times. I only have about 20-30 layers and if WAB can handle it then Experience Builder should be able to handle it even better as it's using the newer JS API.

WAB should not be retired until Experience Builder performance is fixed.

[DanLissick]

I am experiencing the same issues. Below is Esri supports response:

Summary/Documentation:

• The information we received from internal is that this behavior is expected with 4x (i.e., the Maps SDK for JavaScript). Complex polyline and polygon layers are generalized to improve query time. This is different than 3x which loads these geometries differently.
• We also see layers be generalized/optimized by default when they have more than 400,000 vertices to protect the organization's datastore. This is mentioned in our documentation here:
  •  Manage hosted feature layers—ArcGIS Online Help | Documentation.
• From the example layer with which we've reproduced the behavior with in-house, we observed that it's a complex polyline layer that by default, has been optimized by the software upon publishing.
• In general, we have the mantra of no more than one vertex per pixel at any particular scale, meaning that data is being generalized dynamically when being viewed. This isn't bluntly stated in our documentation anywhere, but this topic is touched on in the video resource linked below. Note the discussion at about 24:50 minutes in.
  • Optimize ArcGIS Online Maps and Apps for Audiences of Any Size - Esri Videos: GIS, Events, ArcGIS Pr... 
• This blog also touches on a similar topic of discussion:
  • Essential Configurations for Scalable ArcGIS Online Web Applications.
• My colleague that I was working with has mentioned to internal that the difference between 3x and 4x loading should be documented somewhere - but they would also encourage you to leave feedback directly on our documentation using the 'feedback on this topic?' option on the Map Viewer documentation page as well.
• Additionally, the reason that ArcGIS Field Maps and our other Mobile applications do not display the same behavior is because our mobile apps are not built on the same code base - JavaScript is used for web clients while our mobile apps use a product called ArcGIS Runtime or ArcGIS Maps SDKs for Native Apps | Documentation | Esri Developer.
• The existing Enhancement requesting an improvement in how Map Viewer renders features upon zoom in is ENH-000163087, and has been attached to this case.

I've also provided the feedback you passed along to me in regards to this change and inquired regarding if escalating an Enhancement is possible.

Unfortunately there isn't a set process of escalating an Enhancement in the same way that bugs can be escalated - Our bug escalation documentation page states this directly. However some indirect methods of escalating it would include creating a post on our ArcGIS Ideas forum, which can bring additional views and attention to the issue as our development team does browse the ArcGIS Ideas forum. If you do end up doing this, if you can provide me with the link to the Ideas Page, I can directly attach it to the Enhancement to route other users that create cases for this issue to the same enhancement number.