HTTPS calls order for an ArcGIS Online Web Map

[GeoffroyRicher-Lalonde]

Beginning at version 2.1 (we haven’t tested 2.0), our ArcGIS Online users have been complaining about very slow response times when consuming AGOL Web Maps. The drawing response time seems to be a tiny bit better with 2.4, but the querying response time is still painfully slow. In this example, it takes some 30 seconds for the popup to show up.

It seems that all the features must be completely drawn before any popup could be treated. Doing some investigation with Fiddler, we found out that the queries for the popups (/query?f=json) always seem to be treated after all the other queries that return PBF data (/query?f=pbf).

Is there a reason why the calls are treated in that strict order? Could the popups be prioritized over the drawings?

These slow response times with the 2.x versions force us to be stuck at – the now retired – version 1.18. We have been told that the quicker response times of 1.18 have something to do with an implicit MaxRecordCount of 2000 features that is embedded in this version of the software. If this statement is true, could the MaxRecordCount of AGOL resources be controlled by the administrators in the configuration file in a future release of the software?

Sadly, with these recurrent slow response times with AGOL resources, we are now considering moving to another solution than ArcGIS Earth…

[XiChen]

Hi @GeoffroyRicher-Lalonde  Thank you so much for your detailed analysis and thoughtful feedback. We truly appreciate the time you’ve spent diagnosing the HTTP call patterns and sharing your insights with us. Performance is indeed a top priority for ArcGIS Earth, and your input helps drive our improvements. 

On Popup Query Behavior and Technical Architecture

You’re right that in our current architecture, popup queries (/query?f=json) are tightly coupled with the main rendering thread. This design ensures that the popup information always reflects the currently visible map state, especially when dynamic symbology, filtering, or visibility rules are in place.

However, this also means the popup/query calls are only triggered after all features are fully drawn, leading to noticeable delays, particularly when large datasets are involved or when the rendering thread is under heavy GPU load.

We understand your suggestion about prioritizing or parallelizing these queries. While technically possible, this could lead to inconsistencies, such as popups appearing before their corresponding features are rendered, which we aim to avoid. That said, our engineering team is actively investigating approaches that maintain consistency while improving responsiveness.

Recent and Upcoming Improvements

With ArcGIS Earth 2.4, we've made targeted optimizations to both rendering and feature loading performance, including better handling of feature service throughput and more efficient memory management. While these updates may not completely resolve the popup/rendering coupling, they should noticeably reduce delay in many scenarios.

We are continuing to explore further improvements, including low-level GPU/thread decoupling techniques, and would love to keep you informed as they evolve.

A Quick Follow-Up Question

Are you currently loading many full web maps at once for your use case? If so, and if your workflows permit, we’d love to understand whether loading individual feature services directly could be an option. ArcGIS Earth has undergone significant performance tuning for feature services specifically, and we’ve observed measurable gains when bypassing the additional overhead that sometimes comes with full web map composition.

Thanks again for being so engaged and thorough.

[GeoffroyRicher-Lalonde]

Hello @XiChen. Thank you for your response.

I first tried to add individual feature services from their ArcGIS Online item ID (https://xyzxyz.maps.arcgis.com/home/item.html?id=xyzxyz), and it was the same slow response time (even with services that contain only a few layers).

I then tried to add the same individual feature services from its REST URL (https://services5.arcgis.com/xyzxyz/arcgis/rest/services/xyzxyz/FeatureServer/), and then the time response was better.

But we cannot use the REST URL, because the attachment files (like pictures taken with Field Maps) are only visible if we use the itemID.

• Popup shows the attached pictures when itemID is used :

• Popup won’t show the attachment if REST URL is used :

*the hour in the date is also wrong because of a time zone issue

And while it would be technically possible to use individual feature services rather than web maps, most users would find this cumbersome. If a single user work on 8 different projects, he only has to add 8 web maps to ArcGIS Earth. But because every web map typically contain multiple feature services, the same user will have to add dozens of feature services to ArcGIS Earth. And by skipping the web map container, we lose some rather useful things (ex. grouped layers, layers aliases, etc.).

[YongweiKang]

Hi @GeoffroyRicher-Lalonde  In version 2.5, we provided a solution to configure the featureServiceTilingMode to address the issue you reported. I'd like to know if implementing the featureServiceTilingMode configuration has improved your Identify operation speed. Have you observed performance returning to levels similar to version 1.18 after applying this setting?

<!-- featureServiceTilingMode:
    On – default; use feature tiling whenever the service supports it
    Off – never use feature tiling (may leave some features undisplayed when the view exceeds the service’s MaxRecordCount) -->
<featureServiceTilingMode>On</featureServiceTilingMode>

Thanks,

Yongwei

[GeoffroyRicher-Lalonde]

Hello @YongweiKang.

I tested our heaviest web maps with 2.5 and I don’t see any significant difference between an “On” or an “Off” <featureServiceTilingMode>. In both cases, a query that is requested immediately after a pan or a zoom will take quite some time (typically 15 to 20 seconds).

If every visible layer is fully loaded and the user doesn’t pan or zoom anymore, the query is almost instantaneous. But the “pan + query” or “zoom + query” combination will always take too much time compared to version 1.18.